When the concurrency library's "is current global actor" hook is not
available, assume that we are already executing on the right global
actor. This mimics the behavior of earlier standard libraries when
faced with an isolated conformance, as well as dealing with odd
configurations where the code might not load the concurrency library
yet
At the moment, WebAssembly ends up in this configuration because we
don't run the initialization for the concurrency library. That makes
this also a workaround for issue #82682 / rdar://154762027.
When a conformance becomes part of a value, and that conformance could
potentially be isolated, the value cannot leave that particular
isolation domain. For example, if we perform a runtime lookup for a
conformance to P as part of a dynamic cast `as? any P`, the
conformance to P used in the cast could be isolated. Therefore, it is
not safe to transfer the resulting value to another concurrency domain.
Model this in region analysis by considering whether instructions that
add conformances could end up introducing isolated conformances. In
such cases, merge the regions with either the isolation of the
conformance itself (if known) or with the region of the task (making
them task-isolated). This prevents such values from being sent.
Note that `@concurrent` functions, which never dynamically execute on
an actor, cannot pick up isolated conformances.
Fixes issue #82550 / rdar://154437489
Currently when test subset is not specified, `lit.cfg` provides an error message that refers to test modes instead of tests subsets. Making error messages distinct makes it easier to backtrack in lit.cfg source code when diagnosing the root cause.
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.
Add a fake use for dead-end blocks. This allows gatherKnownLifetimeUses to be
used for local liveness by considering an "unreachable" instruction to generate
liveness. This is important when liveness is used as a boundary within which
access scopes may be extended. Otherwise, we are unable to extend access scopes
into dead-end blocks.
Fixes rdar://154406790 (Lifetime-dependent variable 'X' escapes its
scope but only if actor/class is final)
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.
This overload is disfavored to make sure that it's only used for cases
that don't involve literals, for that `==(StringRef, StaticString) -> Bool`
is preferred. Otherwise these overloads are going to be ambiguous
because both `StringRef`, `StaticString` conform to `ExpressibleByStringLiteral`.
Consider the following example:
```swift
func test(lhs: StringRef) {
lhs == "<<test>>"
}
```
The type-checker used to pick `==(StringRef, StringRef)` overload in this
case because it has homogenous parameter types but this is no longer the
case because this behavior was too aggressive and led to sub-optimal choices
by completely skipping other viable overloads.
Since `StaticString` already represents literals it's better to use
a standard library type and reserve the `(StringRef, StringRef)`
overload to when the literals are not involved.
Resolves: rdar://154719565
In OSSA, the result of an `unchecked_bitwise_cast` must immediately be
copied or `unchecked_bitwise_cast`'d again. In particular, it is not
permitted to borrow it. For example, the result can't be borrowed for
the purpose of performinig additional projections (`struct_extract`,
`tuple_extract`) on the borrowed value. Consequently, we cannot promote
an address if such a promotion would result in such a pattern. That
means we can't promote an address `%addr` which is used like
`struct_element_addr(unchecked_addr_cast(%addr))` or
`tuple_element_addr(unchecked_addr_cast(%addr))`. We can still promote
`unchecked_addr_cast(unchecked_addr_cast(%addr))`.
In ownership-lowered SIL, this doesn't apply and we can still promote
address with such projections.
rdar://153693915
This prevents possible runtime type errors and helped uncovering https://github.com/swiftlang/swift/pull/82777. It also server as an improvement o documentation, as provides inferred type annotations for users of this class and callers of its methods.
