[cfe-users] Is there a way to make clang warn on this code?

[Jordan Rose]

On Mar 17, 2014, at 10:02 , Quentin Colombet <qcolombet at apple.com> wrote:

> Thanks all!
> 
> On Mar 17, 2014, at 9:40 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On Mar 15, 2014, at 19:01 , David Blaikie <dblaikie at gmail.com> wrote:
>> 
>>> On Fri, Mar 14, 2014 at 7:05 PM, Richard Trieu <rtrieu at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20140319/ab17dbfe/attachment.html>