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

Richard Smith richard at metafoo.co.uk
Tue Aug 26 16:57:05 PDT 2014

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

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>

More information about the cfe-dev mailing list