On Mar 19, 2014, at 10:15 AM, Jordan Rose <[email protected]> wrote:
> > On Mar 17, 2014, at 10:02 , Quentin Colombet <[email protected]> wrote: > >> Thanks all! >> >> On Mar 17, 2014, at 9:40 AM, Jordan Rose <[email protected]> wrote: >> >>> >>> On Mar 15, 2014, at 19:01 , David Blaikie <[email protected]> wrote: >>> >>>> On Fri, Mar 14, 2014 at 7:05 PM, Richard Trieu <[email protected]> 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. I understand. Is there a PR or a radar I can follow? Thanks Jordan. -Quentin > > Jordan
_______________________________________________ cfe-users mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
