These aren't currently claimed by anything other
than SILFunctions, and as such are invalid in
regular Swift code. Treat them as SIL type
attributes. Also while here, fix the SIL reference
attributes to be SIL attributes.
A conditional conformance to a protocol does not usually imply
a conformance to the protocol's inherited protocols, because
we have no way to guess what the conditional requirements
should be.
A carveout was added for 'Sendable', so that protocols could
inherit from 'Sendable' retroactively. However, the 'Sendable'
conformance would become conditional, which causes us to
reject a _second_ conditional conformance to such a protocol:
struct G<T> {}
protocol P: Sendable {}
protocol Q: Sendable {}
extension G: P where T: P {}
extension G: Q where T: Q {}
To make this work, tweak the code so that an implied conformance
has the same generic signature as the conforming type, that is,
we force it to be unconditional.
Fixes rdar://122754849
Fixes https://github.com/swiftlang/swift/issues/71544
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.
