[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* 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. 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. (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
