Sema seems to be flagging inout expressions (e.g. &foo) in expression
macros as invalid, setting up a catch 22 where Sema emits an error when
a parameter has the '&' sigil and type checking fails when it doesn't.
This resolves the issue by allowing inout expressions inside macro
expansion expressions.
Resolves https://github.com/swiftlang/swift/issues/82369.
An isolated conformance to a SendableMetatype-inheriting protocol
cannot actually be used in generic code, because the SendableMetatype
requirement itself prevents it. Warn about this case so folks aren't
surprised at runtime.
This is a part of issue #82550 / rdar://154437489.
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.
`TypeSimplifier` may not eliminate type variables from e.g the
pattern types of pattern expansion types since they can remain
unresolved due to e.g having a placeholder count type. Make sure we
eliminate any remaining type variables along with the placeholders.
There's probably a more principled fix here, but this is a quick and
low risk fix we can hopefully take for 6.2.
rdar://154954995
We were effectively working around this previously at the SIL level. This caused
us not to obey the semantics of the actual evolution proposal. As an example of
this, in the following, x should not be considered main actor isolated:
```swift
nonisolated(nonsending) func useValue<T>(_ t: T) async {}
@MainActor func test() async {
let x = NS()
await useValue(x)
print(x)
}
```
we should just consider this to be a merge and since useValue does not have any
MainActor isolated parameters, x should not be main actor isolated and we should
not emit an error here.
I also fixed a separate issue where we were allowing for parameters of
nonisolated(nonsending) functions to be passed to @concurrent functions. We
cannot allow for this to happen since the nonisolated(nonsending) parameters
/could/ be actor isolated. Of course, we have lost that static information at
this point so we cannot allow for it. Given that we have the actual dynamic
actor isolation information, we could dynamically allow for the parameters to be
passed... but that is something that is speculative and is definitely outside of
the scope of this patch.
rdar://154139237
Currently only declarations would get `nonisolated(nonsending)`
inferred if the upcoming flag is enabled, this changes extend
this to apply to asynchronous nonisolated function types as well.
Resolves: rdar://154808850
Serialization and IRGen don't yet support opaque return types that would depend
on querying availability of a custom domain so we need to reject this code to
avoid mis-compiling it.
Inverted availability queries were mis-compiled for zippered libraries because
the code that emits calls to `isOSVersionAtLeastOrVariantVersionAtLeast()` was
not updated when the `if #unavailable` syntax was introduced (at that time
support for zippered libraries had not yet been upstreamed). The result of
these calls is now inverted when appropriate.
To make it easier to manage the growing complexity of supporting availability
queries, Sema now models the relevant information about an availability query
with the new `AvailabilityQuery` type. It encapsulates the domain for the
query, the result if it is known at compile time, and the version tuple
arguments to pass to a runtime invocation if applicable.
Resolves rdar://147929876.
`AvailabilityContext` is now a fundamental type used throughout the compiler,
so it's confusing for `OpaqueUnderlyingTypeChecker` to repurpose this name to
represent an `IfStmt`.
NFC.
We can't assume that type-checking the expression macro in the
parameter will also fail if it fails at the call site since e.g
name lookup may differ. Make sure we only apply this logic to simple
literals.
rdar://154771596
If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
This was added in #80220 to fix a related issue with captures of packs,
but it's even better to sink this down into diagnoseNonSendableTypes(),
so that we can handle packs in parameter position as well.
- Fixes https://github.com/swiftlang/swift/issues/82614.
- Fixes rdar://problem/154649522.
It's shouldn't be possible to use these attributes directly on
the function type that is `@isolated(any)` as per SE-0461 proposal
but it shouldn't preclude declarations that have parameters with
`@isolated(any)` from using them.
Resolves: rdar://154754939
Now that main-actor-isolated deinit can be back-deployed, enable
inference of isolated deinit within main-actor-by-default mode.
Implements rdar://154729369.
When targeting a platform that predates the introduction of isolated
deinit, make a narrow exception that allows main-actor-isolated deinit
to work through a special, inlineable entrypoint that is
back-deployed. This implementation
1. Calls into the real implementation when available, otherwise
2. Checks if we're on the main thread, destroying immediately when
we are, otherwise
3. Creates a new task on the main actor to handle destruction.
This implementation is less efficient than the implementation in the
runtime, but allows us to back-deploy this functionality as far back
as concurrency goes.
Fixes rdar://151029118.
`FunctionConversionExpr` is allowed to modify different attributes
of a type, sometimes it could strip `@Sendable` but keep the same
global actor attribute in place, that needs to be handled explicitly
before performing Sendable checking because in this case there is
going to be no isolation context change for arguments or results.
Resolves: rdar://153646123
When importing C++ methods, Swift always assumes that methods named `begin()` and `end()` are unsafe, since these methods commonly return iterator types that are inherently unsafe in Swift.
Some additional logic in Sema tries to diagnose usages of `.begin()` and `.end()` from Swift and suggest safe alternatives. That logic had a null pointer dereference bug.
rdar://153814676 / resolves https://github.com/swiftlang/swift/issues/82361
use local funcs to implement `defer`, this also fixes several
bugs with that feature, such as it breaking in nonisolated
functions when a default isolation is in effect in the source file.
Change how we compute isolation of local funcs. The rule here is
supposed to be that non-`@Sendable` local funcs are isolated the
same as their enclosing context. Unlike closure expressions, this
is unconditional: in instance-isolated functions, the isolation
does not depend on whether `self` is captured. But the computation
was wrong: it didn't translate global actor isolation between
contexts, it didn't turn parameter isolation into capture isolation,
and it fell through for several other kinds of parent isolation,
causing the compiler to try to apply default isolation instead.
I've extracted the logic from the closure expression path into a
common function and used it for both paths.
The capture computation logic was forcing a capture of the
enclosing isolation in local funcs, but only for async functions.
Presumably this was conditional because async functions need the
isolation for actor hops, but sync functions don't really need it.
However, this was causing crashes with `-enable-actor-data-race-checks`.
(I didn't investigate whether it also failed with the similar
assertion we do with preconcurrency.) For now, I've switched this
to capture the isolated instance unconditionally. If we need to
be more conservative by either only capturing when data-race checks
are enabled or disabling the checks when the isolation isn't captured,
we can look into that.
Fix a bug in capture isolation checking. We were ignoring captures
of nonisolated declarations in order to implement the rule that
permits `nonisolated(unsafe)` variables to be captured in
non-sendable closures. This check needs to only apply to variables!
The isolation of a local func has nothing to do with its sendability
as a capture.
That fix exposed a problem where we were being unnecessarily
restrictive with generic local func declarations because we didn't
consider them to have sendable type. This was true even if the
genericity was purely from being declared in a generic context,
but it doesn't matter, they ought to be sendable regardless.
Finally, fix a handful of bugs where global actor types were not
remapped properly in SILGen.
