<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 4:57 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Tue, Aug 26, 2014 at 4:28 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Tue, Aug 26, 2014 at 4:18 PM, Eugene Toder <span dir="ltr"><<a href="mailto:eltoder@gmail.com" target="_blank">eltoder@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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].</div>



<div>Does anyone object to extending 2) to allow constexpr constructors? The reasoning is that constexpr constructors are not supposed to have any side-effects.</div></div></blockquote><div><br></div></div><div>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.<br>


<br>eg:<br><br>constexpr int func(bool b) { if (b) printf("stuff") return 3; }<br><br>constexpr int x = func(false);<br>const int y = func(true);<br><br>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.</div>

</div></div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div>Yep - I was wondering if we'd be doing the work in many cases anyway & able to leverage that. Sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>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?<br>


</div></div></blockquote><div><br></div></div><div>Might be a bit too much to do.<br><br>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();")</div>

</div></div></div></blockquote><div><br></div></div><div>Maybe under a separate warning flag? </div></div></div></div></blockquote><div><br>Right, yes. </div></div><br></div></div>