Update the logic to correctly handle replacement ranges, and re-enable
the assertion. For now, carve out an exception for attributes on
extensions, I'll try and tackle those in a follow-up.
`visitParsedAccessors` currently iterates over any non-implicit
accessor that happens to be present. This means we end up with
accessors added by macro expansions if the expansion happens before
the ASTScope expansion. Make sure we avoid adding such accessors to
the ASTScope tree, they should instead use their own tree. Ideally
we'd better formalize `visitParsedAccessors` such that it only ever
visits non-expansion accessors, but I'm leaving that for another day.
Rather than looking at their DeclContext, look at the location of
their storage. This allows us to differentiate accessors added by
macro expansions vs accessors that are attached to storage that's
in a macro expansion.
This PR adds a set of DeclAttr.def flags for specifying how a given attribute interacts with `@abi`, and declares a behavior for each existing attribute. Future attributes will be *required* to declare an `@abi` behavior lest they fail a static assert.
Note that the behavior is not actually enforced in this commit—it is merely specified here.
Adds a new method to `DeclAttribute` which can compare two attributes and see if they would be “equivalent” in light of the given decl. “Equivalent” here means that they would have the same effect on the declaration; for instance, two attrs with different source locations can be equivalent, and two attributes with the same arguments in a different order are equivalent if the ordering of those argumetns is not semantically equivalent.
This capability is not yet used in this commit, but in a future commit `@abi` will check if certain attributes are equivalent or not.
ABI-only declarations now inherit `@available`, `@backDeployed`, etc. from their ABI counterpart. This will make it unnecessary to specify these attributes in `@abi`. Also some changes to make sure we suggest inserting `@available` in the correct place.
No tests because the enforcement is not yet in.
ABI-only declarations now inherit access control modifiers like `public` or `private(set)`, as well as `@usableFromInline` and `@_spi`, from their API counterpart. This means these attributes and modifiers don’t need to be specified in an `@abi` attribute.
Very few tests because we aren’t yet enforcing the absence of these attributes.
ABI-only declarations now query their API counterpart for things like `isObjC()`, their ObjC name, dynamic status, etc. This means that `@objc` and friends can simply be omitted from an `@abi` attribute.
No tests in this commit since attribute checking hasn’t landed yet.
Correct an issue with `ImplementsAttr` that would come up if you ever tried to clone an attribute that had been deserialized.
No tests because there’s nothing in the compiler yet that might actually do so.
I am doing this in preparation for adding the ability to represent in the SIL
type system that a function is global actor isolated. Since we have isolated
parameters in SIL, we do not need to represent parameter, nonisolated, or
nonisolated caller in the type system. So this should be sufficient for our
purposes.
I am adding this since I need to ensure that we mangle into thunks that convert
execution(caller) functions to `global actor` functions what the global actor
is. Otherwise, we cannot tell the difference in between such a thunk and a thunk
that converts execution(caller) to execution(concurrent).
In the below, 'Self.A.A' is not a type parameter; rather, since
'Self.A' is concretely known to be 'S', we resolve it as 'S.A',
which performs a name lookup and finds the concrete type alias 'A':
public struct S {
public typealias A = Int
}
public protocol P {
typealias A = S
}
public struct G<T> {}
public protocol Q: P {
typealias B = G<Self.A.A>
}
This is fine, but such a type alias should not participate in
the rewrite system. Let's exclude them like any other invalid
requirement.
The type alias itself is not an error; however, it is an error
to use it from a 'where' clause requirement. This is not
diagnosed yet, though.
Fixes rdar://136686001.
The Error enum synthesized declarations, e.g. the struct and its static accessors, should generally appear to be identical to the underlying Clang definitions. There are some specific use cases where the synthesized declarations are necessary though.
I've added an option for USR generation to override the Clang node and emit the USR of the synthesized Swift declaration. This is used by SwiftDocSupport so that the USRs of the synthesized declarations are emitted.
Fixes 79912
The module name changes the symbol mangling, and also causes
TBDGen to emit linker directives. To separate out these two
behaviors, introduce a terrible hack. If the module name
contains a semicolon (`;`), the part before the semicolon
is the module name for mangling, and the part after the
semicolon is the module name for linker directives.
If there is no semicolon, both module names are identical,
and the behavior is the same as before.
Expand the special-cased ASTWalker behavior for folded SequenceExprs
such that we always walk the folded expression when available. This
ensures that we don't attempt to add the same node multiple times
when expanding ASTScopes during pre-checking.
rdar://147751795
The builtin’s current is signature is:
```
(Any.Type, Any.Type) -> Bool
```
This needs to be changed to this:
```
(any (~Copyable & ~Escapable).Type, any (~Copyable & ~Escapable).Type) -> Bool
```
This requires a bit of support work in AST synthesis.
rdar://145707064
Co-authored-by: Alejandro Alonso <alejandro_alonso@apple.com>
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
