13 Commits

Author SHA1 Message Date
Sergei Barannikov
79f87be688 [clang] Fix several issues in the generated AttrHasAttributeImpl.inc
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)
```

2. 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]].

3. 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.

Differential Revision: https://reviews.llvm.org/D159393
2023-10-10 09:03:55 +03:00
Aaron Ballman
0f1c1be196 [clang] Remove rdar links; NFC
We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071
2023-08-28 12:13:42 -04:00
Mehdi Amini
e0ac46e69d Revert "Remove rdar links; NFC"
This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Differential Revision: https://reviews.llvm.org/D155509
2023-07-17 18:08:04 -07:00
Aaron Ballman
d618f1c3b1 Remove rdar links; NFC
This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847
2023-07-07 08:41:11 -04:00
Aaron Ballman
2edb89c746 Lex arguments for __has_cpp_attribute and friends as expanded tokens
The C and C++ standards require the argument to __has_cpp_attribute and
__has_c_attribute to be expanded ([cpp.cond]p5). It would make little sense
to expand the argument to those operators but not expand the argument to
__has_attribute and __has_declspec, so those were both also changed in this
patch.

Note that it might make sense for the other builtins to also expand their
argument, but it wasn't as clear to me whether the behavior would be correct
there, and so they were left for a future revision.
2021-10-17 07:54:48 -04:00
Richard Smith
4d247e7012 Improve diagnostic for the case when a non-defined function-like macro is used
in a preprocessor constant expression.

llvm-svn: 266495
2016-04-16 00:07:09 +00:00
Aaron Ballman
416b127456 Disable __has_cpp_attribute when not compiling in C++ mode. As this feature test macro only supports C++ style attributes, it doesn't apply to code compiled as C code, and can lead to diagnostics when given a scoped attribute.
This addresses PR23435.

llvm-svn: 236996
2015-05-11 14:09:50 +00:00
Aaron Ballman
a6f759e423 Modify __has_attribute so that it only looks for GNU-style attributes. Removes the ability to look for generic attributes and keywords via this macro, which has the potential to be a breaking change. However, since there is __has_cpp_attribute and __has_declspec_attribute, and given the limited usefulness of querying a generic attribute name regardless of syntax, this seems like the correct path forward.
llvm-svn: 223468
2014-12-05 15:24:55 +00:00
Aaron Ballman
0fa06d879a __has_attribute now understands target-specific attributes. So when you ask whether an ARM target has the "interrupt" attribute, it will return true for ARM and MSP430 targets, and false for others.
llvm-svn: 198897
2014-01-09 22:57:44 +00:00
Richard Smith
baf2912b40 Generalize hack allowing 'const' in __has_attribute (etc) to allow any token
with identifier info. This covers most identifier-like entities (other than
the ISO646 keywords).

llvm-svn: 185895
2013-07-09 00:57:56 +00:00
Fariborz Jahanian
7513fa346c c: small refactoring of checking for __attribute__(const))
per Richard's comment.

llvm-svn: 161786
2012-08-13 21:15:02 +00:00
Jean-Daniel Dupas
7598fadd78 Merge __has_attribute tests. Patch by Jonathan Sauer!
llvm-svn: 151819
2012-03-01 17:45:53 +00:00
Jean-Daniel Dupas
908f130d58 Implement double underscore names support in __has_attribute
llvm-svn: 151809
2012-03-01 14:53:16 +00:00