[cfe-dev] -Wunused-variable for user-defined types

[Richard Smith]

On Tue, Aug 26, 2014 at 4:28 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
>
> On Tue, Aug 26, 2014 at 4:18 PM, Eugene Toder <eltoder at gmail.com> wrote:
>
>> Hi all,
>>
>> I find clang's unused variable warning very useful to keep the code from
>> accumulating garbage over time. For built-in types it works great, but I've
>> noticed that for user-defined types it often misses unused variables. The
>> current logic for user-defined types is to warn on unused variable if 1)
>> the type has a trivial destructor 2) the constructor is either elided or
>> trivial, or the type is marked with warn_unused attribute [1].
>> Does anyone object to extending 2) to allow constexpr constructors? The
>> reasoning is that constexpr constructors are not supposed to have any
>> side-effects.
>>
>
> Not quite true, unfortunately - a constexpr function (or constructor)
> /can/ be used in constexpr contexts but only has to have no side effects
> for the /particular/ codepaths that are called from constexpr contexts.
>
> eg:
>
> constexpr int func(bool b) { if (b) printf("stuff") return 3; }
>
> constexpr int x = func(false);
> const int y = func(true);
>
> is valid code, as I understand it. But we might be able to check the
> particular caller, to see if it's constexpr - but that could have
> performance implications.
>

In some cases, we'll be checking whether the initialization is a constant
expression anyway, and it seems reasonable to extend the warning to cover
those cases. I'm not sure whether there'll be a noticeable performance
penalty for doing this to all local variables; I suspect not, since at
least CodeGen is likely to trigger the constant-evaluation of their
initializers.

What about a check that constructor does not have side-effects, even if
>> it's not marked as constexpr? This can start by using the same code as the
>> one for constexpr checking. Is this the right thing in the compiler, or
>> should this go into clang-tidy?
>>
>
> Might be a bit too much to do.
>
> The aggresive way to do this would be to assume all types are "Value"
> types and warn on all unused variables. Then add an attribute to annotate
> types that have side effects (and even specifically types with scoped side
> effects - such as MutexLock, so you could warn on "MutexLock(n);" but not
> warn on "MutexLock(n), func();")
>

Maybe under a separate warning flag?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140826/1fccd624/attachment.html>