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

[Quentin Colombet]

On Mar 19, 2014, at 10:15 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> 
> 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.
I understand.
Is there a PR or a radar I can follow?

Thanks Jordan.
-Quentin

> 
> Jordan

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