[PATCH] D19625: [libc++] Void-cast runtime-unused variables.

[David Blaikie via cfe-commits]

On Fri, Apr 29, 2016 at 4:59 PM, Stephan T. Lavavej <
stl at exchange.microsoft.com> wrote:

> [David Blaikie]
> > Unused-variable seems pretty low value.
>
> Yeah, but it still has the potential to detect mistakes (e.g. typos, or
> code you intended to write but forgot about).
>
> 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.
>

*nod* Fair, to be sure.


>
> > *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)
>
> 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.)
>
> > My main concern is that this bar will be hard to maintain/will likely
> rot over time, which reduces the value of establishing it
> > (especially when doing so involves adding code like the void casts in
> many places).
>
> 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.
>

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*).


> 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).
>
> > Do you need to run the test cases with warnings enabled to catch them in
> the STL with MSVC?
>
> Yes. Gotta instantiate stuff.
>
> 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.
>

Yeah, for sure.

Thanks for all the details of the situation.


>
> (We do have "include all headers" and "include each header alone" tests
> for other reasons.)
>
> STL
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160429/0853e2da/attachment.html>