Swift ClangImporter now supports concurrency annotations on imported
declarations and their parameters/results, to make it possible to use
imported APIs in Swift safely there has to be a way to annotate
individual parameters and result types with relevant attributes that
indicate that e.g. a block is called on a particular actor or it accepts
a `Sendable` parameter.
To faciliate that `SwiftAttr` is switched from `InheritableAttr` which
is a declaration attribute to `DeclOrTypeAttr`. To support this
attribute in type context we need access to its "Attribute" argument
which requires `AttributedType` to be extended to include `Attr *` when
available instead of just `attr::Kind` otherwise it won't be possible to
determine what attribute should be imported.
Before this change, ParseObjc would call the closing
`MaybeParseAttributes` before it had created Objective-C `ParmVarDecl`
objects (and associated name lookup entries), meaning that you could not
reference Objective-C method parameters in
`__attribute__((diagnose_if))`. This change moves the creation of the
`ParmVarDecl` objects ahead of calling `Sema::ActOnMethodDeclaration` so
that `MaybeParseAttributes` can find them. This is already how it works
for C parameters hanging off of the selector.
This change alone is insufficient to enable `diagnose_if` for
Objective-C methods and effectively is NFC. There will be a follow-up PR
for diagnose_if. This change is still useful for any other work that may
need attributes to reference Objective-C parameters.
rdar://138596211
GlobalMethodPool is a wrapper around DenseMap that does not add
anything except:
using Lists = std::pair<ObjCMethodList, ObjCMethodList>;
This patch removes the wrapper and switches to an alias with "using".
In ReadMethodPool in ASTReader.cpp, we can simplify:
insert(std::make_pair(Sel, SemaObjC::GlobalMethodPool::Lists()))
to:
try_emplace(Sel)
But then try_emplace(Sel).first->second is the same as operator[], so
this patch simplifies the rest of the function.
GlobalMethodPool, the type of MethodPool, is a type wrapping DenseMap
and exposes only a subset of the DenseMap methods.
This patch adds operator[] to GlobalMethodPool so that we can avoid
repeated hash lookups. I don't bother using references or rvalue
references in operator[] because Selector, the key type, is small and
trivially copyable. Note that Selector is a class that wraps a
PointerUnion.
Attribute `optnone` must turn off all optimizations including fast-math
ones. Actually AST nodes in the 'optnone' function still had fast-math
flags. This change implements fixing FP options before function body is
parsed.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch moves `ObjCMethodDecl::ImplementationControl` to a DeclBase.h so that it's complete at the point where corresponsing bit-field is declared. This patch also converts it to a scoped enum `clang::ObjCImplementationControl`.
Instead of emitting a redefinition error, check that definitions are
equivalent and allow such scenario.
A few non-obvious implementation details:
* to avoid multiple definitions in the redeclaration chain we just drop
the new definition after checking for equivalence;
* for checking definition equivalence use ODR hash instead of
ASTStructuralEquivalence because it avoids excessive recursive
deserialization. Though after detecting a mismatch we do deserialize
multiple entities to provide a better error message.
rdar://82908223
Differential Revision: https://reviews.llvm.org/D124286
This change will allow users to call getNullability() without providing an ASTContext.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D140104
Incorrect `isOverriding` flag triggers the assertion
`!Overridden.empty()` in `ObjCMethodDecl::getOverriddenMethods` when a
method is marked as overriding but we cannot find any overrides.
When a method is declared in a category and defined in implementation,
we don't treat it as an override because it is the same method with
a separate declaration and a definition. But with modules we can find
a method declaration both in a modular category and a non-modular category
with different memory addresses. Thus we erroneously conclude the method
is overriding. Fix by comparing canonical declarations that are the same
for equal entities coming from different modules.
rdar://92845511
Differential Revision: https://reviews.llvm.org/D138630
When during parsing we encountered a duplicate `ObjCProtocolDecl`, we
were always emitting an error. With this change we accept
* when a previous `ObjCProtocolDecl` is in a hidden [sub]module;
* parsed `ObjCProtocolDecl` is the same as the previous one.
And in case of mismatches we provide more detailed error messages.
rdar://93069080
Differential Revision: https://reviews.llvm.org/D130327
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)
The high-level changes that achieve this are:
- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.
- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.
- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).
- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).
- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)
The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:
- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)
- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)
- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)
The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:
- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)
- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)
The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.
Depends On D111548
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D126061
This refactor changes the GlobalMethodPool to a class that contains
the DenseMap of methods. This is to allow for the addition of a
separate DenseSet in a follow-up diff that will handle method
de-duplication when inserting methods into the global method pool.
Changes:
- the `GlobalMethods` pair becomes `GlobalMethodPool::Lists`
- the `GlobalMethodPool` becomes a class containing the `DenseMap` of methods
- pass through methods are added to maintain most of the existing code without changing `MethodPool` -> `MethodPool.Methods` everywhere
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D109898
Programmers would like to be able to test direct methods by calling them from a
different linkage unit or mocking them, both of which are impossible. This
patch adds a flag that effectively disables the attribute, which will fix this
when enabled in testable builds. rdar://71190891
Differential revision: https://reviews.llvm.org/D95845
in their corresponding class interfaces
Categories that add protocol conformances to classes with direct members should prohibit protocol
conformances when the methods/properties that the protocol expects are actually declared as 'direct' in the class.
Differential Revision: https://reviews.llvm.org/D92602
Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse.
Patch was reviewed here: https://reviews.llvm.org/D91011
Thank you to aaron, bruno, wyatt and barry for indulging me.
chain for ObjCInterfaceDecls.
Only one such declaration can actually have attributes (the definition,
if any), but generally we assume that we can look for InheritedAttrs on
the most recent declaration.
`addDecl` is making the ivar visible in its primary context. The primary context
of the ivar here is in a 'fragile' ABI the ObjCInterfaceDecl and in a
'non-fragile' ABI the current ObjCImplementationDecl. The additional call to
`makeDeclVisibleInContext` to make the ivar visible in the ObjCInterfaceDecl is
only necessary in the 'non-fragile' case (as in the 'fragile' case the Decl
becomes automatically visible in the ObjCInterfaceDecl with the `addDecl` call
as thats its primary context). See `Sema::ActOnIvar` for where the ivar is put
into a different context depending on the ABI.
To put this into an example:
```
lang=c++
@implementation SomeClass
{
id ivar1;
}
@end
fragile case:
implicit ObjCInterfaceDecl 'SomeClass'
`- ivar1 (in primary context and will be automatically made visible)
ObjCImplementationDecl 'SomeClass'
non-fragile case:
implicit ObjCInterfaceDecl 'SomeClass'
`-<<<ivar1 not visible here and needs to be manually marked as visible.>>>
ObjCImplementationDecl 'SomeClass'
`- ivar1 (in its primary context and will be automatically made visible here)
```
Making a Decl visible multiple times in the same context is inefficient and
potentially can lead to crashes. See D84827 for more info and what this is
breaking.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D84829
`addDecl` is making the Decl visible, so there is no need to make it explicitly
visible again. Making it visible twice will also make the lookup storage less
efficient and potentially lead to crashes, see D84827 for that.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D84828
Also invert the sense of the return value.
As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate name for this function.
I haven't yet changed any of the strings that are output in
ASTDumper.cpp / JSONNodeDumper.cpp / TextNodeDumper.cpp in response to
whether isHidden() is set because
a) I'm not sure whether it's actually desired to change these strings
(would appreciate feedback on this), and
b) In any case, I'd like to get this pure rename out of the way first,
without any changes to tests. Changing the strings that are output in
the various ...Dumper.cpp files will require changes to quite a few
tests, and I'd like to make those in a separate change.
Differential Revision: https://reviews.llvm.org/D81392
Reviewed By: rsmith
When a category/extension doesn't repeat a type bound, corresponding
type parameter is substituted with `id` when used as a type argument. As
a result, in the added test case it was causing errors like
> type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T'
We are already checking that type parameters should be consistent
everywhere (see `checkTypeParamListConsistency`) and update
`ObjCTypeParamDecl` to have correct underlying type. And when we use the
type parameter as a method return type or a method parameter type, it is
substituted to the bounded type. But when we use the type parameter as a
type argument, we check `ObjCTypeParamType` that wasn't updated and
remains `id`.
Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but also
TypeForDecl as we use the underlying type to create a canonical type for
`ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).
This is a different approach to fixing the issue. The previous one was
02c2ab3d8872416589bd1a6ca3dfb96ba373a3b9 which was reverted in
4c539e8da1b3de38a53ef3f7497f5c45a3243b61. The problem with the previous
approach was that `ObjCTypeParamType::desugar` was returning underlying
type for `ObjCTypeParamDecl` without applying any protocols stored in
`ObjCTypeParamType`. It caused inconsistencies in comparing types before
and after desugaring.
Re-applying after fixing intermittent test failures.
rdar://problem/54329242
Reviewed By: erik.pilkington
Differential Revision: https://reviews.llvm.org/D72872
This reverts commit a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7. It causes
intermittent
Clang :: SemaObjC/parameterized_classes_subst.m
test failures on various bots.
When a category/extension doesn't repeat a type bound, corresponding
type parameter is substituted with `id` when used as a type argument. As
a result, in the added test case it was causing errors like
> type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T'
We are already checking that type parameters should be consistent
everywhere (see `checkTypeParamListConsistency`) and update
`ObjCTypeParamDecl` to have correct underlying type. And when we use the
type parameter as a method return type or a method parameter type, it is
substituted to the bounded type. But when we use the type parameter as a
type argument, we check `ObjCTypeParamType` that wasn't updated and
remains `id`.
Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but also
TypeForDecl as we use the underlying type to create a canonical type for
`ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).
This is a different approach to fixing the issue. The previous one was
02c2ab3d8872416589bd1a6ca3dfb96ba373a3b9 which was reverted in
4c539e8da1b3de38a53ef3f7497f5c45a3243b61. The problem with the previous
approach was that `ObjCTypeParamType::desugar` was returning underlying
type for `ObjCTypeParamDecl` without applying any protocols stored in
`ObjCTypeParamType`. It caused inconsistencies in comparing types before
and after desugaring.
rdar://problem/54329242
Reviewed By: erik.pilkington
Differential Revision: https://reviews.llvm.org/D72872
Some methods are sometimes declared in the @implementation blocks which
can cause undiagnosed clashes.
Just write a checkObjCDirectMethodClashes() for this purpose.
Also make sure that "unavailable" selectors do not inherit
objc_direct_members.
Differential Revision: https://reviews.llvm.org/D76643
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
Radar-ID: rdar://problem/59332804, rdar://problem/59782963
Add fixits for messaging self in MRR or using super, as the intent is
clear, and it turns out people do that a lot more than expected.
Allow for objc_direct_members on main interfaces, it's extremely useful
for internal only classes, and proves to be quite annoying for adoption.
Add some better warnings around properties direct/non-direct clashes (it
was done for methods but properties were a miss).
Add some errors when direct properties are marked @dynamic.
Radar-Id: rdar://problem/58355212
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
Differential Revision: https://reviews.llvm.org/D73755
Add fixits for messaging self in MRR or using super, as the intent is
clear, and it turns out people do that a lot more than expected.
Allow for objc_direct_members on main interfaces, it's extremely useful
for internal only classes, and proves to be quite annoying for adoption.
Add some better warnings around properties direct/non-direct clashes (it
was done for methods but properties were a miss).
Radar-Id: rdar://problem/58355212
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
