These changes make the Clang parser recognize expression parameter pack
expansion and initializer lists in attribute arguments. Because
expression parameter pack expansion requires additional handling while
creating and instantiating templates, the support for them must be
explicitly supported through the AcceptsExprPack flag.
Handling expression pack expansions may require a delay to when the
arguments of an attribute are correctly populated. To this end,
attributes that are set to accept these - through setting the
AcceptsExprPack flag - will automatically have an additional variadic
expression argument member named DelayedArgs. This member is not
exposed the same way other arguments are but is set through the new
CreateWithDelayedArgs creator function generated for applicable
attributes.
To illustrate how to implement support for expression pack expansion
support, clang::annotate is made to support pack expansions. This is
done by making handleAnnotationAttr delay setting the actual attribute
arguments until after template instantiation if it was unable to
populate the arguments due to dependencies in the parsed expressions.
As for now, the categories are printed in an arbitrary order which
depends on the addresses of dynamically allocated objects. The patch
sorts them in an alphabetical order thus making the output stable.
Differential Revision: https://reviews.llvm.org/D113477
Completion now looks more like function/member completion:
used
alias(Aliasee)
abi_tag(Tags...)
Differential Revision: https://reviews.llvm.org/D108109
Also clang ClangAttrEmitter for -gen-clang-attr-doc-table to be
like all other tablegen: Produce a .inc file with the generated bits
and put the static parts into a regular .cpp file that includes the
.inc file.
The previous implementation was insufficient for checking statement
attribute mutual exclusion because attributed statements do not collect
their attributes one-at-a-time in the same way that declarations do. So
the design that was attempting to check for mutual exclusion as each
attribute was processed would not ever catch a mutual exclusion in a
statement. This was missed due to insufficient test coverage, which has
now been added for the [[likely]] and [[unlikely]] attributes.
The new approach is to check all of attributes that are to be applied
to the attributed statement in a group. This required generating
another DiagnoseMutualExclusions() function into AttrParsedAttrImpl.inc.
Just because an attribute is a statement attribute doesn't mean it's
not also a declaration attribute. In Clang, there are not currently any
DeclOrStmtAttr attributes that require mutual exclusion checking, but
downstream clients discovered this issue.
Currently, when one or more attributes are mutually exclusive, the
developer adding the attribute has to manually emit diagnostics. In
practice, this is highly error prone, especially for declaration
attributes, because such checking is not trivial. Redeclarations
require you to write a "merge" function to diagnose mutually exclusive
attributes and most attributes get this wrong.
This patch introduces a table-generated way to specify that a group of
two or more attributes are mutually exclusive:
def : MutualExclusions<[Attr1, Attr2, Attr3]>;
This works for both statement and declaration attributes (but not type
attributes) and the checking is done either from the common attribute
diagnostic checking code or from within mergeDeclAttribute() when
merging redeclarations.
Clang currently automates a fair amount of diagnostic checking for
declaration attributes based on the declarations in Attr.td. It checks
for things like subject appertainment, number of arguments, language
options, etc. This patch uses the same machinery to perform diagnostic
checking on statement attributes.
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
This is a re-commit. The previous commit was reverted because it exposed
a pre-existing bug that has since been fixed / worked around; see
PR48434.
Differential Revision: https://reviews.llvm.org/D91311
This change exposed a pre-existing issue with deserialization cycles
caused by a combination of attributes and template instantiations
violating the deserialization ordering restrictions; see PR48434 for
details.
A previous commit attempted to work around PR48434, but appears to have
only been a partial fix, and fixing this properly seems non-trivial.
Backing out for now to unblock things.
This reverts commit 98f76adf4e and
commit a64c26a47a.
This is really just a workaround for a more fundamental issue in the way
we deserialize attributes. See PR48434 for details.
Also fix tablegen code generator to produce more correct indentation to
resolve buildbot issues with -Werror=misleading-indentation firing
inside the generated code.
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
Differential Revision: https://reviews.llvm.org/D91311
There are two factory functions used to create a semantic attribute,
Create() and CreateImplicit(). CreateImplicit() does not need to
specify the source range of the attribute since it's an implicitly-
generated attribute. The same logic does not apply to Create(), so
this removes the default argument from those declarations to avoid
accidentally creating a semantic attribute without source location
information.
ns_error_domain can be used by, e.g. NS_ERROR_ENUM, in order to
identify a global declaration representing the domain constant.
Introduces the attribute, Sema handling, diagnostics, and test case.
This is cherry-picked from a14779f504
and adapted to updated Clang APIs.
Reviewed By: gribozavr2, aaron.ballman
Differential Revision: https://reviews.llvm.org/D84005
WG14 N2481 was adopted with minor modifications at the latest WG14 meetings.
The only modification to the paper was to correct the date for the deprecated
attribute to be 201904L (the corrected date value will be present in WG14
N2553 when it gets published).
ClangAttrEmitter.cpp generates ParsedAttr derived classes with virtual overrides in them (which end up in AttrParsedAttrImpl.inc); this patch ensures these generated functions are marked override, and not (redundantly) virtual.
I hesitate to say NFC since this does of course affect the behavior of the generator code, but the generated code behaves the same as it did before, so it's NFC in that sense.
Differential Revision: https://reviews.llvm.org/D83616
GCC 10.1 introduced support for the [[]] style spelling of attributes in C
mode. Similar to how GCC supports __attribute__((foo)) as [[gnu::foo]] in
C++ mode, it now supports the same spelling in C mode as well. This patch
makes a change in Clang so that when you use the GCC attribute spelling,
the attribute is automatically available in all three spellings by default.
However, like Clang, GCC has some attributes it only recognizes in C++ mode
(specifically, abi_tag and init_priority), which this patch also honors.
Currently square-bracket-style (CXX11/C2X) attribute names are normalised to
start with :: if they don't have a namespace. This is a bit odd, as such
names are rejected when parsing, so don't do this.
Differential Revision: https://reviews.llvm.org/D76704
This makes it possible for plugin attributes to actually do something, and also
removes a lot of boilerplate for simple attributes in SemaDeclAttr.cpp.
Differential Revision: https://reviews.llvm.org/D31342
Discovered in a downstream, it is often useful to have slightly
different semantics for an attribute based on its namespace, however our
spelling infrastructure doesn't consider namespace when deciding to
elide the enum list. The result is that the solution for a case where
an attribute has slightly different semantics based on a namespace
requires checking against the integer value, which is fragile.
This patch makes us always emit the spelling enum if there is more than
1 and we're generating the header.
Differential Revision: https://reviews.llvm.org/D76289
The name field is optional if the custom code is supplied, so this updates the
documentation for LangOpt and introduces a tablegen warning if both custom code
and a language option name are supplied.
After this change, clang spends ~200ms parsing Attrs.inc instead of
~560ms. A large part of the cost was from the StringSwitch
instantiations, but this is a good way to avoid similar problems in the
future.
Reviewed By: aaron.ballman, rjmccall
Differential Revision: https://reviews.llvm.org/D76040
When constructing a ParsedAttr the ParsedAttrInfo gets looked up in the
AttrInfoMap, which is auto-generated using tablegen. If that lookup fails then
we look through the ParsedAttrInfos that plugins have added to the registry and
check if any has a spelling that matches.
Differential Revision: https://reviews.llvm.org/D31338
This doesn't do anything on its own, but it's the first step towards
allowing plugins to define attributes. It does simplify the
ParsedAttrInfo generation in ClangAttrEmitter a little though.
Differential Revision: https://reviews.llvm.org/D31337
This patch implements an almost complete handling of OpenMP
contexts/traits such that we can reuse most of the logic in Flang
through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP.
All but construct SIMD specifiers, e.g., inbranch, and the device ISA
selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From
these definitions we generate the enum classes `TraitSet`,
`TraitSelector`, and `TraitProperty` as well as conversion and helper
functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`.
The above enum classes are used in the parser, sema, and the AST
attribute. The latter is not a collection of multiple primitive variant
arguments that contain encodings via numbers and strings but instead a
tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`).
The changes to the parser make it more forgiving when wrong syntax is
read and they also resulted in more specialized diagnostics. The tests
are updated and the core issues are detected as before. Here and
elsewhere this patch tries to be generic, thus we do not distinguish
what selector set, selector, or property is parsed except if they do
behave exceptionally, as for example `user={condition(EXPR)}` does.
The sema logic changed in two ways: First, the OMPDeclareVariantAttr
representation changed, as mentioned above, and the sema was adjusted to
work with the new `OpenMPTraitInfo`. Second, the matching and scoring
logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat
representation of the `match` clause that is not tied to clang.
`OpenMPTraitInfo` provides a method to generate this flat structure (see
`struct VariantMatchInfo`) by computing integer score values and boolean
user conditions from the `clang::Expr` we keep for them.
The OpenMP context is now an explicit object (see `struct OMPContext`).
This is in anticipation of construct traits that need to be tracked. The
OpenMP context, as well as the `VariantMatchInfo`, are basically made up
of a set of active or respectively required traits, e.g., 'host', and an
ordered container of constructs which allows duplication. Matching and
scoring is kept as generic as possible to allow easy extension in the
future.
---
Test changes:
The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have
been auto generated to match the new warnings and notes of the parser.
The "subset" checks were reversed causing the wrong version to be
picked. The tests have been adjusted to correct this.
We do not print scores if the user did not provide one.
We print spaces to make lists in the `match` clause more legible.
Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim
Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D71830
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
There are three significant changes here:
- Most of the methods to read various embedded structures (`APInt`,
`NestedNameSpecifier`, `DeclarationName`, etc.) have been moved
from `ASTReader` to `ASTRecordReader`. This cleans up quite a
bit of code which was passing around `(F, Record, Idx)` arguments
everywhere or doing explicit indexing, and it nicely parallels
how it works on the writer side. It also sets us up to then move
most of these methods into the `BasicReader`s that I'm introducing
as part of abstract serialization.
As part of this, several of the top-level reader methods (e.g.
`readTypeRecord`) have been converted to use `ASTRecordReader`
internally, which is a nice readability improvement.
- I've standardized most of these method names on `readFoo` rather
than `ReadFoo` (used in some of the helper structures) or `GetFoo`
(used for some specific types for no apparent reason).
- I've changed a few of these methods to return their result instead
of reading into an argument passed by reference. This is partly
for general consistency and partly because it will make the
metaprogramming easier with abstract serialization.
r371875 moved some functionality around to a Basic header file, but
didn't move its definitions as well. This patch moves some things
around so that shared library building can work.
llvm-svn: 371985
Apparently Clang complains about the name hiding here in a way that my
GCC build does not, so a shocking number of buildbots decided to tell me
about it. Change the name of the variable to prevent the name hiding
and hope we don't have to fix this again.
llvm-svn: 371876
Steffen Larsen