<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 4:59 PM, Stephan T. Lavavej <span dir="ltr"><<a href="mailto:stl@exchange.microsoft.com" target="_blank">stl@exchange.microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[David Blaikie]<br>
<span class="">> Unused-variable seems pretty low value.<br>
<br>
</span>Yeah, but it still has the potential to detect mistakes (e.g. typos, or code you intended to write but forgot about).<br>
<br>
I figured I'd submit a patch, since there weren't actually that many occurrences, and they were all easy to silence in a targeted manner, following existing conventions.<br></blockquote><div><br></div><div>*nod* Fair, to be sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> *nod* just a question of whether the work is worth it - which is mostly totally up to you (& you've decided it's worth it for you)<br>
<br>
</span>For the time being, I've decided that fixing signed/unsigned mismatch and similar warnings is too much work, so I'm globally suppressing them. (There were hundreds.)<br>
<span class=""><br>
> My main concern is that this bar will be hard to maintain/will likely rot over time, which reduces the value of establishing it<br>
> (especially when doing so involves adding code like the void casts in many places).<br>
<br>
</span>When my work is finished (currently 3132 tests are passing out of 4541), I expect that we'll start running libcxx's tests in our automation, which will detect regressions rapidly and reliably.<br></blockquote><div><br></div><div>It'd be great to have this sort of stuff upstream (in a public facing buildbot/on LLVM's community buildbot infrastructure) if that's a possibility - saves you the hassle of roundtripping/externalizing your results & let's the community fix things as they occur. But I know it can be a pain/expensive/etc to setup infrastructure (I've a GDB buildbot that's been down for months because I haven't found the time to bring it all back online... *shamecube*).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For this particular warning, the suppression mechanism is super simple and easy to maintain (if you don't mention a variable at runtime, have the void cast).<br>
<span class=""><br>
> Do you need to run the test cases with warnings enabled to catch them in the STL with MSVC?<br>
<br>
</span>Yes. Gotta instantiate stuff.<br>
<br>
There are two main scenarios in which you'd want to see warnings in the STL. The first is when the STL itself is doing something bad. The second is when user code causes the STL to do something bad. For example, giving less<int32_t> to an STL algorithm with an int64_t range. That'll truncate, but the truncation happens within the algorithm.<br></blockquote><div><br></div><div>Yeah, for sure.<br><br>Thanks for all the details of the situation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(We do have "include all headers" and "include each header alone" tests for other reasons.)<br>
<span class="HOEnZb"><font color="#888888"><br>
STL<br>
</font></span></blockquote></div><br></div></div>