On Fri, Apr 29, 2016 at 4:59 PM, Stephan T. Lavavej < s...@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 >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
