This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Void-cast runtime-unused variables.
ClosedPublic

Authored by STL_MSFT on Apr 27 2016, 2:34 PM.

Details

Summary

[libc++] Void-cast runtime-unused variables.

Also, remove unused names in exception handlers, remove an unused array, move a conditionally-used array, and remove unused argc/argv.

Fixes MSVC "warning C4101: unreferenced local variable".

Diff Detail

Event Timeline

STL_MSFT updated this revision to Diff 55324.Apr 27 2016, 2:34 PM
STL_MSFT retitled this revision from to [libc++] Void-cast runtime-unused variables..
STL_MSFT updated this object.
STL_MSFT added reviewers: mclow.lists, EricWF.
STL_MSFT added a subscriber: cfe-commits.

Are there any issues with these changes? I tried to follow the existing practice for void-casting, including the comment (although the comments varied).

EricWF requested changes to this revision.Apr 28 2016, 6:31 PM
EricWF edited edge metadata.

One inline change requested.

test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
24421

Isn't this unused as well on non-apple platforms?

24422

Move str inside the #ifdef __APPLE__ instead.

test/std/numerics/rand/rand.device/eval.pass.cpp
33

This looks OK, but I noticed that *technically* the spec only says the exception type is derived from std::exception.

However if we can keep testing this exception without bothering anybody I say we do.

This revision now requires changes to proceed.Apr 28 2016, 6:31 PM
STL_MSFT updated this revision to Diff 55683.Apr 29 2016, 4:22 PM
STL_MSFT updated this object.
STL_MSFT edited edge metadata.

This moves "str" as requested. It also adds void casts to another file, and removes an unused argc/argv pair.

I'm not sure why we'd want to compile the test suite with -Wunused-variable
(& even if we did, I imagine Clang's doesn't fire here because the
variables are used, just in non-evaluated contexts?)? Is there a benefit to
it being clean of unused-variable warnings? (in Clang's test case we just
aggressively disable warnings rather than making all the code warning
clean, for example)

STL_MSFT marked 2 inline comments as done.Apr 29 2016, 4:34 PM

What I'm doing is running libcxx's tests against MSVC's compiler and libraries. I could aggressively suppress warnings (and indeed I'm doing that for the noisiest, lowest-value warnings), but instead I'm building the tests with /W4 (our highest supported level). It is indeed somewhat annoying to make tests warning-free, although it does find real issues occasionally (e.g. the broken assert that I reported first). The real value is verifying that the headers are warning-free, which has the potential to catch issues in the product code. This is possibly a difference in philosophy between VC's STL and libc++, because I believe libc++ uses the "system header" behavior to avoid all warnings from system headers.

test/std/numerics/rand/rand.device/eval.pass.cpp
33

This one's problematic for MSVC for other reasons, but I have no issue with system_error here, so I haven't changed it.

[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

Our test harness has a switch to enable warnings. I would be happy to set up a bot in that configuration. It would probably be easier than setting up one that uses MSVC.
Currently that mode disables the unused variable warnings but if/when STL cleans all of those we can turn that warning on to prevent regressions.

Thanks again for cleaning these warnings up. I've been meaning to get to it *eventually*.

No problem! With these changes, my test runs are currently clean wrt "warning C4100: unreferenced formal parameter" and "warning C4101: unreferenced local variable", but note that (1) Clang may emit unused-variable warnings in somewhat different situations, and (2) I've still got 25% of the tests failing to compile, which may be hiding further warnings.

EricWF accepted this revision.May 2 2016, 12:18 PM
EricWF edited edge metadata.
This revision is now accepted and ready to land.May 2 2016, 12:18 PM
EricWF closed this revision.May 2 2016, 12:23 PM

r268284.

No problem! With these changes, my test runs are currently clean wrt "warning C4100: unreferenced formal parameter" and "warning C4101: unreferenced local variable", but note that (1) Clang may emit unused-variable warnings in somewhat different situations, and (2) I've still got 25% of the tests failing to compile, which may be hiding further warnings.

I'm hoping Clang is pretty similar. I guess we will see. I'm going to hold off setting up a bot for a while still.