This is an archive of the discontinued LLVM Phabricator instance.

Create diagnostic group for definition deprecation warning
ClosedPublic

Authored by nuriamari on Jun 27 2023, 8:05 AM.

Details

Summary

In https://reviews.llvm.org/D126664, a warning is introduced
warning against the deprecated out of line definition of a
static constexpr member in C++17 and later. Prior to this patch,
the only diagnostic group controlling this diagnostic was -Wdeprecated,
which controls many many diagnostics. This patch creates
a diagnostic group specifically for this warning so it can
be controlled in isolation, while also being included with -Wdeprecated.

Diff Detail

Event Timeline

nuriamari created this revision.Jun 27 2023, 8:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 8:05 AM
nuriamari added inline comments.
clang/test/CXX/basic/basic.def/p3.cpp
1 ↗(On Diff #534993)

I'm not familiar with the naming convention of these test files. https://reviews.llvm.org/D126664 included a change in p2.cpp, and there is also a p4.cpp in the same directory, so I somewhat arbitrarily named this test p3.cpp. If these are meant to somehow correspond to the C++ standard or similar, please let me know.

nuriamari published this revision for review.Jun 27 2023, 9:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 9:38 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I think it's a bit odd that we'd leave const under -Wdeprecated but separate constexpr out into its own warning flag, but I'm also not opposed. Can you explain the need a bit more though? I think our belief was that silencing this diagnostic was pretty trivial (delete the line in question), so we wouldn't need a separate diagnostic group for it.

Also, these changes should have a release note added to clang/docs/ReleaseNotes.rst.

clang/test/CXX/basic/basic.def/p3.cpp
1 ↗(On Diff #534993)

Tests that live in clang/test/CXX/ or clang/test/C are for testing specific details of the standard specification. In C, we track based on which N-numbered document the feature was proposed in, and in C++ we track based on stable name (basic/basic.def) and paragraph number (p2.cpp) of the changes being tested.

I think your new test should live in clang/test/SemaCXX/ as that's where we put tests for more general compiler behaviors like warning flags.

I think it's a bit odd that we'd leave const under -Wdeprecated but separate constexpr out into its own warning flag, but I'm also not opposed.

Would moving both const and constexpr into their own warning flag work? I don't really see cases where you'd want to disable only one or the other.

Can you explain the need a bit more though? I think our belief was that silencing this diagnostic was pretty trivial (delete the line in question), so we wouldn't need a separate diagnostic group for it.

In our case we have libraries that are consumed both with say C++14 and C++17, so we can't just delete them, we've needed to add a standard version check. Admittedly not a huge change either, but we ran into many occurrences of this warning trying to adopt the latest Clang. I suppose I don't see the downside of a little more granular control.

Also, these changes should have a release note added to clang/docs/ReleaseNotes.rst.

Will do.

I think it's a bit odd that we'd leave const under -Wdeprecated but separate constexpr out into its own warning flag, but I'm also not opposed.

Would moving both const and constexpr into their own warning flag work? I don't really see cases where you'd want to disable only one or the other.

I think that would work better, yes.

Can you explain the need a bit more though? I think our belief was that silencing this diagnostic was pretty trivial (delete the line in question), so we wouldn't need a separate diagnostic group for it.

In our case we have libraries that are consumed both with say C++14 and C++17, so we can't just delete them, we've needed to add a standard version check. Admittedly not a huge change either, but we ran into many occurrences of this warning trying to adopt the latest Clang. I suppose I don't see the downside of a little more granular control.

Ah, I see now, thank you. Backcompat would be harder without this kind of granular control, so I'm okay with this direction.

  • Create entry in release notes
  • Move test to appropriate location
  • Expand test to include const warning controlled in the same warning group
nuriamari added inline comments.Jul 10 2023, 11:36 AM
clang/docs/ReleaseNotes.rst
380

Happy to use a better flag name, if anyone has ideas. Considered expanding to be more descriptive, but its already quite long.

clang/test/SemaCXX/redundant-out-of-line-static-constexpr-member-def-diag.cpp
10

Unbeknownst to me, the const variant of this diagnostic (still about a static constexpr member, but defined out-of-line with const) is already controlled via the same diagnostic group. Is this the behavior you expect @aaron.ballman?

aaron.ballman accepted this revision.Jul 13 2023, 4:53 AM

LGTM! Do you need me to land this on your behalf? If so, what name and email address would you like me to use for patch attribution? (If I'm landing it, I can fix up the release note for you when landing.)

clang/docs/ReleaseNotes.rst
380–383

Reworded a bit

clang/test/SemaCXX/redundant-out-of-line-static-constexpr-member-def-diag.cpp
10

Oh, nice! I wasn't aware we already covered that under the same group.

This revision is now accepted and ready to land.Jul 13 2023, 4:53 AM

LGTM! Do you need me to land this on your behalf? If so, what name and email address would you like me to use for patch attribution? (If I'm landing it, I can fix up the release note for you when landing.)

I do. Nuri Amari - nuri.amari99@gmail.com would be great, thanks.

This revision was landed with ongoing or failed builds.Jul 16 2023, 9:36 AM
This revision was automatically updated to reflect the committed changes.