Ttheir availability is going to match the property itself.
This is a workaround for lazy type-checking because synthesis
of accessors for such properties requires a reference to
`self` which won't be available because pattern binding
for the variable was skipped.
Resolves: rdar://129359362
Resolves: rdar://159463230
Resolves: https://github.com/swiftlang/swift/issues/84041
(cherry picked from commit 6e7de5c1e0)
`nonisolated(nonsending)` is not presented in interface types
which means that references to declarations that have this attribute
require a function conversion to apply it. Function conversion
checking should detect that and avoid sendability checking for
situations like that but there is really no conversion there.
(cherry picked from commit ce3310050b)
The isolation doesn't change in this cause and making function type
non-Sendable means that it woun't be able to leave the current concurrency
domain and the compiler won't generate a thunk.
(cherry picked from commit 40c9674dfd)
Explicit closure expressions gets their isolation inferred during
actor isolation checking, if they appear as a sub-expression to
a function conversion we need to delay function checking until
the closure was processed. It shouldn't matter for other cases.
(cherry picked from commit 61fbaa7af7)
If there are no explicit concurrency attributes, isolated parameters,
or captures associated with the closure it should infer `nonisolated(nonsending)`
for the parent conversion injected by the solver (this conversion is injected
because the solver cannot check captures to elide it).
The change pushes `isIsolationInferenceBoundaryClosure` check down
with added benefit of getting preconcurrency context from the parent.
(cherry picked from commit 3ae34e8e68)
As a follow-up fix for https://github.com/swiftlang/swift/pull/83545, avoid
incorrectly diagnosing isolated deinit availability during module emission
jobs, which skip type checking non-inlinable function bodies and therefore
don't build accurate availability scopes for those bodies. It's ok to skip
these diagnostics during module emission since they should still be emitted
during compilation jobs.
Resolves rdar://161178785.
Allow referencing an `@_spi_available` decl in extensions to
`@_spi_available` types. This is a narrow fix as it should really be
handled as part of the context check but that check is currently too
permissive.
Fow now let's narrowly allow legal code. And then we should look at
revisiting the SPI availability logic, separate it from normal SPI and
treat more like availability.
Adding a test comparing the behavior of `@_spi` with `@_spi_available`
to document the current implementation.
rdar://159292698
The first bug is that we weren't computing isolation correctly for
nested defers. This is an unlikely pattern of code, but it's good to fix.
The second bug is that getActorIsolationOfContext was looking through
defers, but getActorIsolation itself was not. This was causing defer
bodies to be emitted in SILGen without an isolation parameter, which
meant that #isolation could not possibly provide the right value. Fixing
this involves teaching SILGen that non-async functions can have
nonisolated(nonsending) isolation, but that's relatively straightforward.
This commit doesn't fix #isolation or adequately test SILGen, but that'll
be handled in a follow-up.
Explanationion: Function pointer types wee always considered fragile in
C++ mode, this manifested as a regression when interfacing with glibc.
Issues: rdar://159184118
Original PRs: #84040
Risk: Low, this only removes a spurious error for library evolution.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Otherwise the "nonisolated nonsending by default" mode blows up as
distributed thunk signatures dont match expectations.
This undoes the fix from https://github.com/swiftlang/swift/pull/83940
and applies the fix on the synthesis side of the distributed thunks,
such that they are @concurrent always -- which keeps their old semantics
basically, regardless of what "default" mode we have.
Explanation: We generate declarations in the C++ interop header with
"unavailable" annotations when we cannot export something to C++. These
declarations can collide with existing names. Previously, there were no
ways to resolve these name collisions. This PR introduces a new
attribute to hide declarations from the interop header.
Issues: rdar://158843666
Original PRs: #82616
Risk: Low, this adds a new, straightforward code path.
Testing: Added a compiler test.
Reviewers: @egorzhdan
the new NonisolatedNonsendingByDefault upcoming feature breaks remote
calls in distributed actors, because the expected isolation doesn't
match and the runtime swift_distributed_execute_target_resume will
crash.
This is a short term fix to unblock adopters, however preferably we
should mark the thunks as nonisolated(nonsending), though that seems to
be more involved.
resolves rdar://159247975
If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
(cherry picked from commit 29b04f4a63)
This fixes a runtime crash when a `weak` reference to a C++ foreign reference type is used.
Instead of a runtime crash, Swift would now emit a compiler error saying that `weak` keyword is incompatible with foreign reference types.
rdar://124040825 / resolves https://github.com/swiftlang/swift/issues/83080
(cherry picked from commit 9abadf5483)
This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
(cherry picked from commit fe1ae75711)
Just like `@preconcurrency` for concurrency, this attribute is going
to allow exhaustiveness error downgrades for enums that were retroactively
marked as `@extensible`.
(cherry picked from commit 498430afaf)
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
(cherry picked from commit a0ae93d3a8)
Parameter type could be represented by an associated type which is
bound to a concrete type by an extension, `AbstractFunction::getType()`
should map it into context before returning because the construct is
that it always produces a function type.
Resolves: rdar://156955193
(cherry picked from commit 32b97d0e2a)
Explanation: There were some scenarios where we could call an unsafe
function without marking the expression as unsafe. These affect mostly
cases where the function's result is passed to another function or
returned. This PR makes sure we always flag functions with unsafe return
types, even if their result is not stored anywhere for later use.
Issues: rdar://157237301
Original PRs: #83520
Risk: Low, worst case scenario the user has to add redundant unsafe
keywords in strict memory safe mode.
Testing: Added a compiler test.
Reviewers: @DougGregor
The availability of isolated deinits were being misdiagnosed for nominal types
that were available prior to the module's deployment target when
`-target-min-inlining-version` was specified. Only the body of an isolated
deinit uses runtime functionality that requires a minimum runtime version, so
availability must be checked in the context of the body of the deinit, not the
interface of the deinit.
Resolves rdar://157563752.
Such references used to be downgraded until Swift 6 but since the
context is `@preconcurrency` it should be possible for API authors
to introduce concurrency annotations such as `@Sendable` without
breaking clients even when they are compiled in Swift 6 mode.
Resolves: rdar://157061896
(cherry picked from commit 5ee673f358c9dd7dbbfe58f02bc78af60e0377b8)
The constraint solver does not reliably give closures a function type
that includes `nonisolated(noncaller)`, even when the immediate context
requires a conversion to such a type. We were trying to work around this
in SILGen, but the peephole only kicked in if the types matched exactly,
so a contextual conversion that e.g. added `throws` was still emitting
the closure as `@concurrent`, which is of course the wrong semantics.
It's relatively easy to avoid all this by just rewriting the closure's
type to include `nonisolated(nonsending)` at a point where we can reliably
decide that, and then SILGen doesn't have to peephole anything for
correctness.
Fixes rdar://155313349
Make explicit "nonisolated" also not special on protocols, so a
nonisolated protocol does not suppress default isolation.
SendableMetatype is the proper way to suppress default isolation for a
protocol.
Unfortunately, these rules made it appear like issue #82168
was fixed, when in fact it was not. Keep the test case, but as a
failing test, and we'll investigate separately.
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
Extensions of nonisolated types can get default isolation from context
(e.g., @MainActor) independently. This was previously true for members,
but not conformances, and recently regressed for members. Fix the logic
to consistently allow such extensions to be default main-actor
isolated, which affects both their members and conformances.
Fixes rdar://156644976.
decls that are in a main actor isolated context.
This prevents `@MainActor` from being inferred in a context where
it cannot be used, while still allowing main actor code to be used
in local contexts that are also main actor isolated.
(cherry picked from commit 858e145069)
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
`_openExistential` is type-checked in a special way which
means that we need to explicitly inject `nonisolated(nonsending)`
isolation when forming a reference to this builtin.
(cherry picked from commit 358869ff54)
`withoutActuallyEscaping` is type-checked in a special way which
means that we need to explicitly inject `nonisolated(nonsending)`
isolation when forming a reference to this builtin.
(cherry picked from commit 48f4d7b688)
In the effects checker, we were propagating the "has an unsafe use
site" outside of an `unsafe` expression. The result of this is that we
would not produce a warning for silly expressions like `unsafe unsafe
ptr.pointee`, where the first (outer) `unsafe` is unnecessary. Stop
propagating that bit so we properly diagnose the spurious "unsafe".
Fixes issue #82315 / rdar://153672668.
The present approach is not prudent because `@concurrent` synchronous
functions, a natural extension, are a likely-to-happen future direction,
whereas the current inference rule is entirely grounded on `@concurrent`
being exclusive to async functions.
If we were to ship this rule, we would have to keep the promise for
backwards compatibility when implementing the aforementioned future
direction, replacing one inconsistency with another, and possibly
introducing new bug-prone expression checking code.
```swift
func foo(_: () -> Void) {}
func foo(_: () async -> Void) {}
// In a future without this change and `@concurrent` synchronous
// functions accepted, the first call resolves to the first overload,
// and the second call resolves to the second, despite `@concurrent` no
// longer implying `async`.
foo { }
foo { @concurrent in }
```
This change also drops the fix-it for removing `@concurrent` when used
on a synchronous closure. With the inference rule gone, and the
diagnosis delayed until after solution application, this error raises a
fairly balanced choice between removing the attribute and being
explicit about the effect, where a unilateral suggestion is quite
possibly more harmful than useful.
(cherry picked from commit 58d5059617)
