This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Add warning pragma macros in the test suite
ClosedPublic

Authored by philnik on Mar 13 2022, 8:04 AM.

Diff Detail

Event Timeline

philnik created this revision.Mar 13 2022, 8:04 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 13 2022, 8:04 AM
philnik requested review of this revision.Mar 13 2022, 8:04 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 13 2022, 8:04 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
EricWF requested changes to this revision.Mar 13 2022, 3:26 PM
EricWF added a subscriber: EricWF.

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.

This revision now requires changes to proceed.Mar 13 2022, 3:26 PM
EricWF added inline comments.Mar 13 2022, 3:27 PM
libcxx/test/std/containers/sequences/array/array.tuple/tuple_element.fail.cpp
15

What happened here?

philnik updated this revision to Diff 414964.Mar 13 2022, 3:47 PM
philnik marked an inline comment as done.
  • Fix CI

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.

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?

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.

I mostly agree, but I don't think this is the PR for that.

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.

EricWF added inline comments.Mar 13 2022, 5:27 PM
libcxx/src/filesystem/filesystem_common.h
47–49

I would much rather we annotate each function than disable this for the entire file.
It's a useful warning.

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.
That warning is specifically what the test is trying to generate. If it's not being generated, there's something very weird going on.

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.

EricWF added inline comments.Mar 13 2022, 5:30 PM
libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.pass.cpp
28–29

What version was -Wconstant-evaluated added to Clang?

36

Where did this go?

philnik updated this revision to Diff 415084.Mar 14 2022, 6:31 AM
philnik marked 6 inline comments as done.
  • 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.

ldionne accepted this revision as: ldionne.Mar 14 2022, 8:01 AM

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.

EricWF added inline comments.Mar 14 2022, 8:01 AM
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.

ldionne accepted this revision.Mar 15 2022, 7:19 PM

I think this can be rebased. If CI passes and there's nothing subtle to call out, this LGTM.

EricWF accepted this revision.Mar 16 2022, 10:36 AM

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.

This revision is now accepted and ready to land.Mar 16 2022, 10:36 AM
This revision was automatically updated to reflect the committed changes.