Details
- Reviewers
Mordante ldionne CaseyCarter EricWF - Group Reviewers
Restricted Project - Commits
- rG14324fa4285f: [libc++] Add warning pragma macros in the test suite
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Every single warning we disable should come with a comment explaining why the warning isn't real and why we're not fixing it some other way. We shouldn't encourage suppressing warnings.
libcxx/test/std/containers/sequences/array/array.tuple/tuple_element.fail.cpp | ||
---|---|---|
15 | What happened here? |
I mostly agree, but I don't think this is the PR for that.
libcxx/test/std/containers/sequences/array/array.tuple/tuple_element.fail.cpp | ||
---|---|---|
15 | What are you asking exactly? Why I removed it? Because it doesn't seem to suppress any warnings. Why was it there in the first place? I don't know. |
Have @ldionnes changes to enable warnings in the test suite been submitted yet? Maybe that's why you're not seeing some of the warnings you removed.
Can you double check that (A) The headers aren't included with -isystem or -cxx-isystem and that _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER is defined
when you've tested this?
I disagree. Changing the code changes the git blame and makes it harder to do archology on it.
If you're modifying the code in this patch, it's the time to ensure it has a comment.
That said, almost all of the changes already do have comments.:-D
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.rel/three_way.pass.cpp | ||
---|---|---|
22 | Clang respects GCC's pragmas. We don't need both here. | |
libcxx/test/support/unique_ptr_test_helper.h | ||
137 | I think this needs to stay. |
libcxx/src/filesystem/filesystem_common.h | ||
---|---|---|
47–49 | I would much rather we annotate each function than disable this for the entire file. | |
610–612 | Had this always been missing a pop? | |
libcxx/test/libcxx/minimal_cxx11_configuration.pass.cpp | ||
28 | There was a reason this went before the type traits includes I suspect. | |
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.cnstr/PR20855_tuple_ref_binding_diagnostics.fail.cpp | ||
15 | I suspect this is needed, and the test just wasn't run with warnings enabled. Otherwise something is broken. | |
libcxx/test/std/containers/sequences/array/array.tuple/get.fail.cpp | ||
14 | Don't make this harder to compile for people who don't use LIT.. | |
libcxx/test/std/utilities/meta/meta.rel/is_convertible_fallback.pass.cpp | ||
22–27 | No. The #define NEEDS to be the first thing that occurs. Otherwise the entire test may not test anything. | |
libcxx/test/std/utilities/meta/meta.unary/meta.unary.prop/is_destructible.pass.cpp | ||
13 | Again, I don't think this change was actually tested with warnings enabled. |
- Fix CI; Address comments
libcxx/src/filesystem/filesystem_common.h | ||
---|---|---|
47–49 | Almost all functions here are unused, because they are all in an anonymous namespace (and some are also declared static just to be safe). Shouldn't these functions be declared inline and not in an anonymous namespace/declared static? Or what is the rationale behind doing these very weird things? | |
610–612 | No. You removed it for some reason in e3081d5d96fa2940bbec51d978f98384781ea979. | |
libcxx/test/libcxx/minimal_cxx11_configuration.pass.cpp | ||
28 | Actually, I have no idea why I left that in. The warning is explicitly disabled. | |
libcxx/test/std/containers/sequences/array/array.tuple/get.fail.cpp | ||
14 | There are almost 500 uses of ADDITIONAL_COMPILE_FLAGS in the libc++ test suite. Are there even people who don't use lit to run the tests? If yes, what is the problem with using lit? | |
libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.pass.cpp | ||
28–29 | In Clang 10. | |
36 | All major implementations are supporting std::is_constant_evaluated() for two years now (OK, in two days for two years). GCC since version 9, libc++ since version 9 and MSVC since VS 2019 16.5. I see no reason to guard this anymore. We don't guard any other tests with feature-test macros. | |
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.rel/three_way.pass.cpp | ||
22 | We decided in D119295 that the best way (we could think of) is to fully separate the GCC and Clang warnings, because there are GCC warnings that Clang doesn't recognize and the macro would be kind-of lying if it disabled warnings for clang while being called _LIBCPP_GCC_DIAGNOSTIC_IGNORED. |
My understanding is that this patch doesn't remove any warnings (if so, @philnik please call them out) -- it only introduces new macros to push/pop warnings consistently like we've started doing in the libc++ source code itself. It also seems to remove a few unused pragmas, which I think is fine as a fly-by.
So I'm fine with this, however I would like to wait for D120684 to land before we land this one to make sure everything still works.
libcxx/src/filesystem/filesystem_common.h | ||
---|---|---|
47–49 | I *think* it's because this header is included elsewhere e.g. in the test suite, but I'm speculating. Eric should know for sure, since he wrote it. | |
libcxx/test/std/containers/sequences/array/array.tuple/get.fail.cpp | ||
14 | @EricWF FWIW, our intent is for everyone who uses the test suite to be doing so using Lit. The Lit setup has been made more flexible to make it possible for everyone to use it with the configuration they need. I'm not saying it's perfect, but that's the intent. Otherwise, it's just too difficult to keep the test suite independent of how Lit works. |
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.cnstr/PR20855_tuple_ref_binding_diagnostics.fail.cpp | ||
---|---|---|
15 | Nevermind. I tried it for myself. Don't know what's going on but this is fine to remove. Same thing with the other warnings I complained about. Sorry about that. I'm often dumb. | |
libcxx/test/support/unique_ptr_test_helper.h | ||
137 | Or it doesn't ignore me. |
I think this can be rebased. If CI passes and there's nothing subtle to call out, this LGTM.
I still don't love that this patch codifies a way to disable warnings in tests. We don't want to do that, so it's fine that it's ugly to do.
But otherwise I'm OK with this.
I would much rather we annotate each function than disable this for the entire file.
It's a useful warning.