This is an archive of the discontinued LLVM Phabricator instance.

[clang] Fix several issues in the generated AttrHasAttributeImpl.inc
ClosedPublic

Authored by barannikov88 on Sep 1 2023, 7:31 PM.

Details

Summary
  1. The generated file contained a lot of duplicate switch cases, e.g.:
switch (Syntax) {
case AttributeCommonInfo::Syntax::AS_GNU:
  return llvm::StringSwitch<int>(Name)
...
    .Case("error", 1)
    .Case("warning", 1)
    .Case("error", 1)
    .Case("warning", 1)
  1. Some attributes were listed in wrong places, e.g.:
case AttributeCommonInfo::Syntax::AS_CXX11: {
if (ScopeName == "") {
  return llvm::StringSwitch<int>(Name)
...
    .Case("warn_unused_result", LangOpts.CPlusPlus11 ? 201907 : 0)

warn_unused_result is a non-standard attribute and should not be
available as [[warn_unused_result]].

  1. Some attributes had the wrong version, e.g.:
case AttributeCommonInfo::Syntax::AS_CXX11: {
} else if (ScopeName == "gnu") {
  return llvm::StringSwitch<int>(Name)
...
    .Case("fallthrough", LangOpts.CPlusPlus11 ? 201603 : 0)

[[gnu::fallthrough]] is a non-standard spelling and should not have the
standard version. Instead, __has_cpp_attribute should return 1 for it.

There is another issue with attributes that share spellings, e.g.:

    .Case("interrupt", true && (T.getArch() == llvm::Triple::arm || ...) ? 1 : 0)
    .Case("interrupt", true && (T.getArch() == llvm::Triple::avr) ? 1 : 0)
...
    .Case("interrupt", true && (T.getArch() == llvm::Triple::riscv32 || ...) ? 1 : 0)

As can be seen, __has_attribute(interrupt) would only return true for
ARM targets. This patch does not address this issue.

Diff Detail

Event Timeline

barannikov88 created this revision.Sep 1 2023, 7:31 PM
Herald added a project: Restricted Project. · View Herald Transcript
barannikov88 requested review of this revision.Sep 1 2023, 7:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2023, 7:31 PM

Update one more test

barannikov88 added inline comments.Sep 1 2023, 7:52 PM
clang/test/Preprocessor/has_attribute.cpp
35

For the context, the attribute is defined with the following spellings:

let Spellings = [CXX11<"", "nodiscard", 201907>,
                 C23<"", "nodiscard", 202003>,
                 CXX11<"clang", "warn_unused_result">,
                 GCC<"warn_unused_result">];

Should I create a github PR instead?

No, existing PRs can stay there. I'm waiting for @aaron.ballman, our resident attributes guru, to look at that - even if the changes look reasonably good to me

barannikov88 edited the summary of this revision. (Show Details)Sep 5 2023, 9:38 AM
aaron.ballman accepted this revision.Sep 6 2023, 5:04 AM
aaron.ballman added a subscriber: Endill.

LGTM, though please add a release note because there are user-facing changes regarding what the feature test macros return or what spellings are available (both of which can potentially break code, but I don't see much evidence that it will in practice).

clang/test/Preprocessor/has_c_attribute.c
15–19

This matches the behavior we have today but I think it also shows a bug -- I think clang::warn_unused_result should be available in both C++ and C.

@Endill -- if you're still looking for a good first issue, that might be a reasonable one to tackle. The attribute currently uses CXX11 as the spelling, it should instead use Clang as the spelling so the feature works in C the same as in C++.

This revision is now accepted and ready to land.Sep 6 2023, 5:04 AM

Add a release note

@aaron.ballman I added a release note as requested. Please see if it looks the way it should.

Add a hyphen

aaron.ballman accepted this revision.Oct 9 2023, 6:04 AM

LGTM -- that release note is *awesome*, thank you for that!