Centralize the exportability checking logic for nested functions in the
`DeclExportabilityVisitor` utility. This logic was previously added to SILGen
but there should not be special casing for nested functions at that layer.
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
Now that API descriptions are emitted during module build jobs when
`-emit-api-descriptor-path` is specified and the build system has been updated
to pass that flag when the output is needed, the `swift-api-extract` frontend
alias is no longer used. Delete it and the tests that were specific to invoking
`swift-api-extract`.
Resolves rdar://116537394.
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
The de-virtualizer utility didn't handle indirect error results when de-virtualizing class or actor methods.
This resulted in a missing argument for the indirect error result in the new try_apply instruction.
rdar://130545338
I'm working to fully remove this method, but because it's
used and/or implemented in a few places, I'm backing it out
incrementally. This just changes the abstract method so I can
delete the implementors in a subsequent PR without breaking
anything.
- While an opaque borrow access occurs to part of a value, the entire scope of
the access needs to be treated as a liveness range, so add the `EndAccess`es
to the liveness range.
- The SIL verifier may crash the compiler on SILGen-generated code when the
developer's source contains consume-during-borrow code patterns. Allow
`load_borrow` instructions to be marked `[unchecked]`, which suppresses
verifier checks until the move checker runs and gets a chance to properly
diagnose these errors.
Fixes rdar://124360175.
A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:
```swift
struct S<T: ~Copyable, E> {
func f() where E == Never {}
}
```
Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.
We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.
resolves rdar://130179698
From the perspective of the IR, we are changing SILIsolationInfo such that
inferring an actor instance means looking at equivalence classes of values where
we consider operands to look through instructions to be equivalent to their dest
value. The result is that cases where the IR maybe puts in a copy_value or the
like, we consider the copy_value to have the same isolation info as using the
actor directly. This prevents a class of crashes due to merge failings. Example:
```swift
actor MyActor {
init() async {
init(ns: NonSendableKlass) async {
self.k = NonSendableKlass()
self.helper(ns)
}
func helper(_ newK: NonSendableKlass) {}
}
```
Incidently, we already had a failing test case from this behavior rather than
the one that was the original genesis. Specifically:
1. If a function's SILIsolationInfo is the same as the isolation info of a
SILValue, we assume that no transfer actually occurs.
2. Since we were taking too static of a view of actor instances when comparing,
we would think that a SILIsolationInfo of a #isolation parameter to as an
argument would be different than the ambient's function isolation which is also
that same one. So we would emit a transfer non transferrable error if we pass in
any parameters of the ambient function into another isolated function. Example:
```swift
actor Test {
@TaskLocal static var local: Int?
func withTaskLocal(isolation: isolated (any Actor)? = #isolation,
_ body: (consuming NonSendableValue, isolated (any Actor)?) -> Void) async {
Self.$local.withValue(12) {
// We used to get these errors here since we thought that body's isolation
// was different than the body's isolation.
//
// warning: sending 'body' risks causing data races
// note: actor-isolated 'body' is captured by a actor-isolated closure...
body(NonSendableValue(), isolation)
}
}
}
```
rdar://129400019
