This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Reject standard attributes which are extensions in libcpp-uglify-attributes
ClosedPublic

Authored by philnik on Mar 7 2023, 8:02 AM.

Details

Summary

This adds a list of attributes which can be pretty to be able to reject attributes which were introduced in a later C++ standard.
Fixes #61196

Diff Detail

Event Timeline

philnik created this revision.Mar 7 2023, 8:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2023, 8:02 AM
Herald added a subscriber: jdoerfert. · View Herald Transcript
philnik requested review of this revision.Mar 7 2023, 8:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2023, 8:02 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik added inline comments.Mar 7 2023, 8:04 AM
libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
72

The old way is fundamentally broken. IMO it's better to produce slightly wrong hints in an edge case instead of never producing hints.

Since this fixes a bug, should we add regression tests?

libcxx/include/barrier
138

This looks odd, either we are Standard compliant and we can use [[nodiscard]] or this is an extension in some language modi, but we're not using _LIBCPP_NODISCARD_EXT. Do you know why this is needed here?

libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
50

This count feels extremely error prone, maybe an array per language version. This then has some duplicates but feels easier to maintain. It also allows for the removal of an attribute in a later version of the standard.

72

The TODO sound do. Don't try to do something seems like maintaining the status-quo, while a todo implies a change.

Can you add in the comment what is "fundamentally" broken?

I don't mind not fixing, but then let's state that and not put a TODO. That way the comment doesn't show when grepping for TODOs.

philnik added inline comments.Mar 7 2023, 12:29 PM
libcxx/include/barrier
138

<barrier> itself is an extension in C++14 and C++17. This is how I noticed that we have them as extensions.

libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
50

I don't disagree, but one array per version seems also error-prone.

ldionne added inline comments.Mar 13 2023, 9:57 AM
libcxx/include/barrier
138

Yeah, this is a weird case but I think using __nodiscard__ is right here. We support barrier in C++14 so we can't use nodiscard, but barrier is specified to have nodiscard unconditionally so using _LIBCPP_NODISCARD_EXT also doesn't make sense.

libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
49

FWIW I would do this:

std::vector<std::string> get_standard_attributes(const clang::LangOptions& lang_opts) {
  std::vector<std::string> attributes = {
    // C++11 attributes
    "noreturn",
    "carries_dependency"
  };

  if (lang_opts.CPlusPlus14)
    attributes.push_back("deprecated");

  ...

  return attributes;
}

Not quite as efficient, but much more straightforward and TBH efficiency here probably doesn't matter.

72

I am not sure I understand what's your preferred resolution here. Do you want a TODO like @philnik did here, or do you want him to instead explain why this is fundamentally broken (i.e. we don't have the right Clang API) and make it a normal comment, but not a TODO?

Personally, I would go with (2) unless there is a proper solution to fix the TODO, in which case I would do it in this patch.

philnik updated this revision to Diff 506372.Mar 19 2023, 3:25 AM
philnik marked 3 inline comments as done.

Address comments

philnik added inline comments.Mar 19 2023, 3:25 AM
libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
72

I've reworded the TODO for now. I'd really like to fix the problem, so I'd rather keep the TODO.

Mordante accepted this revision.Apr 7 2023, 9:45 AM

LGTM! I added some comments, but only feedback and no changes are needed.

libcxx/include/barrier
138

Thanks for the comments. I still don't like it, but no objection either.

libcxx/test/tools/clang_tidy_checks/uglify_attributes.cpp
29

Interesting I recalled more attributes in C++11, but according to cppreference this is correct.

49

+1 I really like this a lot better.

This revision is now accepted and ready to land.Apr 7 2023, 9:45 AM
This revision was landed with ongoing or failed builds.Apr 7 2023, 12:11 PM
This revision was automatically updated to reflect the committed changes.
rsmith added a subscriber: rsmith.Apr 7 2023, 2:25 PM

There still appear to be problems after this patch. It looks like a test that defines these tokens to "weird" things and then tries including the libc++ headers would have caught these issues.

libcxx/include/__config
1190

This is still broken. We'll fail to compile this header if msvc or no_unique_address is defined as a macro that expands to something other than a single identifier. My understanding is that the direction on the bug was to remove the msvc::no_unique_address handling entirely.

1200

This is also still broken, if no_unique_address is defined as a macro.

There still appear to be problems after this patch. It looks like a test that defines these tokens to "weird" things and then tries including the libc++ headers would have caught these issues.

That would have caught this specific case, but wouldn't catch using other attributes in their pretty variants. I rather go conservative here, i.e. allow specific attributes instead of trying to ban some. I'll try to add something to also check the preprocessor checks in another patch.