This cycle break means that some attributes introduced by
member-attribute macros aren't getting processed. I'm still reducing a
test case while I look for a fix, but for now I'm reverting this
change to address a regression for macros.
Fixes rdar://108456284.
If a parameter is marked consuming and its type is Copyable, that
parameter has eager-move semantics. Apply that attribute to the
SILFunctionArgument corresponding to the parameter.
rdar://108385761
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
This method was misleading. The majority of callers (all but one!) don't want
to unconditionally treat all locations in any macro expansion buffer the
same way, because the code also must handle nested macro expansions. There
is one part of SourceKit (and possibly others) that really do want to ignore
all macro expansions, but those can be handled within SourceKit / IDE code,
because I don't believe this utility is useful in the frontend.
inside closures while type checking a macro expansion.
PreCheckExpr, ConstraintGenerator, and other walkers do not walk into macro
expansions. However, the implementation of this macro walking behavior in
ASTWalker would skip any declaration that appears inside any macro expansion
buffer. This is incorrect for cases where the parent is in the same macro
expansion buffer, because the local declaration is not inside a new macro
expansion. This caused bogus errors when type checking expanded macro expressions
containing closures with local declarations, because pre-check and constraint
generation mistakenly skipped local pattern bindings.
When populating the name lookup tables for a nominal type, we were only
visiting declarations with peer macros within the nominal type
declaration itself. Also visit the members of extensions of the
nominal type.
Without this change, peer-macro-defined members of extensions are not
visible.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
How did we go this long without having the right context? Who knows.
The fix is trivial and obvious.
The failure mode here is that we wouldn't get an appropriate generic
context in the result type of a macro, so we would complain about
generic parameters not meeting their own generic requirements.
Sometimes we build a `MacroExpansionDecl` from a `MacroExpansionExpr`.
Sometimes we do it the other way. In both cases, we risk the two
copies of must-by-shared data (macro arguments, resolved macro
reference, etc.) getting out-of-sync.
Instead, share the storage between the two representations when we
create one from the other, so that they cannot get out-of-sync. This
allows us to eliminate the extremely-dodgy `cacheOutput` call earlier.
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
The `@MainActor` global actor constraint on a declaration does not carry an
inherent ABI impact and therefore use of this constraint should not be limited
to OS versions where Swift concurrency is available.
Resolves rdar://105610970
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
If a declaration is unavailable but also has an `introduced:` availability
version, treat that as an indication that it is considered ABI and should be
linked as if it were available.
Part of rdar://106673713
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
The interface-type computation in OpaqueReadOwnershipRequest is causing
a cycle with `@objc` names for the getter/setter of a property. Break
the cycle by relying on the fact that `@objc` names can only be
directly on the getter/setter, not on some other accessor, so we can
go through `getAccessor` for both cases.
I am not convinced that we won't have additional issues related to the
interface-type computation in OpaqueReadOwnershipRequest, but I
couldn't see any obvious ones in the code base either.
Fixes rdar://106575164.
* Weakly reference ModuleDecl from PackageUnit
* Add PackageUnit decl context getter and use it for a package AccessScope
* Return module decl referenced by PackageUnit in getModuleScopeContext and getParentModule
* Handle package acl in access scope checkers
* Remove AccessLimitKind
* Fix tests
Resolves rdar://104987295, rdar://105187216, rdar://104723918
