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

Eugene Toder eltoder at gmail.com
Tue Aug 26 17:44:18 PDT 2014

> On Tue, Aug 26, 2014 at 4:28 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 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.
>> Good point! I missed that.

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

> On Tue, Aug 26, 2014 at 4:57 PM, Richard Smith <richard at metafoo.co.uk>
>  wrote:
>> 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.
> Yep - I was wondering if we'd be doing the work in many cases anyway &
> able to leverage that. Sounds good.
For the unused variable warning we don't need to check every local variable
-- only the unused ones. But this does make the code change a lot more
involved. How about a change that's only triggered by constexpr
constructors with no arguments? My understanding is such constructors
should not have side-effects (7.1.5/5).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140826/7f61cb03/attachment.html>

More information about the cfe-dev mailing list