On Mar 17, 2014, at 10:02 , Quentin Colombet <qcolom...@apple.com> wrote:
> Thanks all! > > On Mar 17, 2014, at 9:40 AM, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Mar 15, 2014, at 19:01 , David Blaikie <dblai...@gmail.com> wrote: >> >>> On Fri, Mar 14, 2014 at 7:05 PM, Richard Trieu <rtr...@google.com> wrote: >>>> Quentin, >>>> >>>> Clang does not have a warning for uninitialized fields in class methods. >>>> I've looked before to add a warning to flag any unused fields at the end of >>>> the a constructor. However, there were good reasons to have uninitialized >>>> fields, such as having an Init() method later that initializes the fields, >>>> or a guard variable to protect against uninitialized use. Also, >>>> -Wuninitialized typically warns on the use of an uninitialized variable, >>>> not >>>> the mere presence of one. >>>> >>>> The other idea is to do cross method analysis, either using the control >>>> flow >>>> of a program to determine which methods are used in which order, or testing >>>> methods against constructors. Such an analysis would likely be too >>>> expensive, and would be more suited for static analysis. >>> >>> We already have at least one cross-method analysis which could >>> actually be used as the basis for the warning under discussion here: >>> >>> -Wunused-member-variable. This warning only fires if there are no >>> friends and a private member in a situation where all member functions >>> are defined in one translation unit. So we could use this to show >>> that there's no initialization of the variable anywhere, but there are >>> uses of it. (essentially the same as -Wunused-member-variable, except >>> allow reads as well) >> >> The analyzer also catches the particular case in your stripped-down test >> file, and should do so on real code as long as it's all visible in one >> translation unit. It'd be a lot harder to make this a cross-TU analysis, of >> course. > The actual problem is cross-TU. > Is there a plan or a way to run the analyzer on several TU? It's a big problem that's not likely to happen any time soon. Clang is just too much designed to work on one TU at a time, so we'd need a whole lot of new infrastructure to handle this. It is something we want to do some day. Jordan
_______________________________________________ cfe-users mailing list cfe-users@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
