The `convenience` keyword is not accepted on actor initializers because the
compiler infers this status automatically and actors cannot be subclassed.
However, internally the compiler still computes whether an actor init is a
convenience init and this implicit status has been leaking through accidentally
in printed `.swiftinterface` files. This was noticed because in Swift 6 the
presence of the keyword is diagnosed as an error, making `.swiftinterface`
files unparseable for modules containing actors with convenience inits.
For Swift 6, I'm just going to suppress the error in `.swiftinterface` files
regardless of language mode. In future releases of the compiler, though, it can
stop printing the `convenience` keyword on these inits altogether, though.
Resolves rdar://130857256.
Playgrounds cannot display any macro expansions anyway and the @Observable macro
can generate instrumentations that don't typecheck and/or reference missing
functions.
rdar://112122752
Having package-name flag in non-package interfaces causes them to be built as if
belonging to a package, which causes an issue for a loading client outside of the
package as follows.
For example, when building X that depends on A with the following dependency chain:
X --> A --> B --(package-only)--> C
1. X itself is not in the same package as A, B, and C.
2. When dependency scanning X, and opening up B, because the scan target is in a
different package domain, the scanner decides that B's package-only dependency
on C is to be ignored.
3. When then finally building A itself, it will load its dependencies, but because
the .private.swiftinterface of A still specifies -package-name, when it loads
B, it will then examine its dependencies and deem that this package-only dependency
on C is required.
Because (2) and (3) disagree, we get an error now when building the private A textual interface.
rdar://130701866
The changes in https://github.com/apple/swift/pull/72410 caused a regression
when checking availability in the following example:
```
// warning: Setter for 'hasDeprecatedSetter' is deprecated: ...
x[y.hasDeprecatedSetter] = ...
```
The result of `y.hasDeprecatedSetter` is being passed as an argument to the
subscript and its setter will not be called. To fix this,
`ExprAvailabilityWalker` now consistently creates a new default
`MemberAccessContext` when descending into any `Argument`, since the access
context for the expressions surrounding the call should not affect the
arguments to the call.
Additionally, `MemberAccessContext` has been refactored to better model context
state transitions. Instead of only modeling which accessors will be called, the
enumeration's members now reflect the possible states that
`ExprAvailabilityWalker` can be in during its traversal. This should hopefully
make it easier to follow the logic for traversal of `LoadExpr`s and arguments.
Resolves rdar://130487998.
Build an accurate macro dependency for swift caching. Specifically, do
not include not used macro plugins into the dependency, which might
cause false negatives for cache hits.
This also builds the foundation for future improvement when dependency
scanning will determine the macro plugin to load and swift-frontend do
not need to redo the work.
rdar://127116512
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
An async @objc method only checks if its completion handler parameter is null if ClangImporter forces it to. This is fine for @objc with a generated header, because the generated header always declares the parameter _Nonnull, but clients ignore that annotation and pass nil anyway often enough that for @objc @implementation, we ought to be defensive.
We can achieve this by simply making the completion handler’s type Optional—SILGen already looks for this and knows what to do when it sees it.
Fixes rdar://130527373.
This fixes a regression from https://github.com/swiftlang/swift/pull/72369.
The compiler now incorrectly diagnoses use of an unavailable setter in this
example:
```
func increaseBrightness(in window: UIWindow) {
// warning: setter for 'screen' was deprecated in iOS 13.0
window.screen.brightness = 1.0
}
```
While the setter is deprecated, it would not be called in the generated code
since `screen` is a reference type and there is no writeback through the setter
for `screen` after setting `brightness`.
Resolves rdar://129679658
This check was added in 38e305cfdc,
and was used to detect whether there may be
something invalid about the members that were
necessary for conformance derivation. However this
is no longer the case, a nominal should only ever
be marked invalid these days if it is either in an
unsupported DeclContext, or it's a redeclaration.
The synthesis logic ought to be resilient against
invalid members.
Additionally, this check wasn't even necessarily
looking at the nominal, it could have been
looking at an ExtensionDecl. In that case, we could
have still attempted to synthesize with invalid
members. As such, it seems unlikely this check is
providing any real benefit, let's remove it.
Previously `getHashableConformance` was attempting
to find the conformance itself, which could fail
(rdar://129620291). Instead, pass down the
known protocol conformance that we're deriving
a witness for. No test case unfortunately as I
haven't been able to come up with a reproducer.
rdar://129620291
Out of an abundance of caution, we:
1. Left in parsing support for transferring but internally made it rely on the
internals of sending.
2. Added a warning to tell people that transferring was going to
be removed very soon.
Now that we have given people some time, remove support for parsing
transferring.
rdar://130253724
Without this, we were hitting weird behaviors in flow_isolation.swift only when
compiling in Swift 5 mode.
Consider the following example:
```
func fakeTask(@_inheritActorContext _ x: sending @escaping () async -> ()) {}
actor MyActor {
var x: Int = 5
var y: Int = 6
var hax: MyActor? = nil
init() {
fakeTask {
// Warning! You can remove await
// Error! Cannot access actor state in nonisolated closure.
_ = await self.hax
}
}
}
```
The reason why this was happening is that we were not understanding that the
closure passed to fakeTask is not part of the init and has different isolation
from the init (it is nonisolated but does not have access to the init's state).
This then caused us to exit early and not properly process the isolation
crossing point there.
Now, we properly understand that a sending inheritActorContext closure (just
like an @Sendable closure) has this property in actor initializers.
There is only one call site of this helper function, so we are not gaining any
flexibility by doing this. It only makes it harder to reason about what the
function actually does without providing any benefit.
I am doing this before I make in the next commit an actual semantic changing
commit to ease review.
Consider the following piece of code and what the isolation is of the closure
literal passed to doSomething():
```swift
func doSomething(_ f: sending () -> ()) { ... }
@MyCustomActor
func foo() async {
doSomething {
// What is the isolation here?
}
}
```
In this case, the isolation of the closure is @MyCustomActor. This is because
non-Sendable closures are by default isolated to their current context (in this
case @MyCustomActor since foo is @MyCustomActor isolated). This is a problem
since
1. Our closure is a synchronous function that does not have the ability to hop
to MyCustomActor to run said code. This could result in a concurrency hole
caused by running the closure in doSomething() without hopping to
MyCustomActor's executor.
2. In Region Based Isolation, a closure that is actor isolated cannot be sent,
so we would immediately hit a region isolation error.
To fix this issue, by default, if a closure literal is passed as a sending
parameter, we make its isolation nonisolated. This ensures that it is
disconnected and can be transferred safely.
In the case of an async closure literal, we follow the same semantics, but we
add an additional wrinkle: we keep support of inheritActorIsolation. If one
marks an async closure literal with inheritActorIsolation, we allow for it to be
passed as a sendable parameter since it is actually Sendable under the hood.
The reason why I am doing this is that:
1. We don't support no escaping closure parameters today and would like
to leave the design space open.
2. These closures are bitwise copyable/trivial so marking them as
specifically consuming doesn't really make sense.
If the property comes from a different module the compiler shouldn't
attempt to diagnose `GlobalIsolation` problems based in the current
module flags otherwise it would create issues when i.e. a variable/property
from a module built with `-swift-version 5` that gets referenced
by a module that is built with `-swift-version 6` that has stricter
local concurrency requirements.
See https://forums.swift.org/t/swift-6-language-mode-being-passed-to-dependencies/72622
for further discussion.
A better solution would be to move the check to `ActorIsolationChecker`
or `DeclChecker` but that would be too risky for 6.0.
