This makes the code easier to write and also prevents any lifetime issues from a
diagnostic outliving the SmallString due to diagnostic transactions.
(cherry picked from commit 010fa39f31)
Specifically in terms of printing, if NonisolatedNonsendingByDefault is enabled,
we print out things as nonisolated/task-isolated and @concurrent/@concurrent
task-isolated. If said feature is disabled, we print out things as
nonisolated(nonsending)/nonisolated(nonsending) task-isolated and
nonisolated/task-isolated. This ensures in the default case, diagnostics do not
change and we always print out things to match the expected meaning of
nonisolated depending on the mode.
I also updated the tests as appropriate/added some more tests/added to the
SendNonSendable education notes information about this.
(cherry picked from commit 14634b6847)
I am doing this so that I can change how we emit the diagnostics just for
SendNonSendable depending on if NonisolatedNonsendingByDefault is enabled
without touching the rest of the compiler.
This does not actually change any of the actual output though.
(cherry picked from commit 4ce4fc4f95)
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
(cherry picked from commit c12c99fb73)
Explanation: C++ interop synthesizes certain forwarding functions in an
_ObjC module. This confuses MemberImportVisibility. This patch adds
logic to work this around by keeping a mapping between the synthesized
and the original function and looks up where the synthesized functions
belong to based on the original functions' parent module.
Scope: C++ forward interop when MemberImportVisibility is enabled.
Issues: rdar://154887575
Original PRs: #82840
Risk: Low, a narrow change makes getModuleContextForNameLookupForCxxDecl more
precise, and it is only used with MemberImportVisibility.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @tshortli, @hnrklssn
A call to a `@preconcurrency` function goes through a function conversion
that removes `Sendable` from existentials among other things. Implement
support for this by bitcasting indirect return slots whose type differs
from the formal indirect return type in concurrency markings only.
Fixes rdar://154240007
Centralize the logic for figuring out the conformances for the various
init_existential* instructions in a SILIsolationInfo static method, and
always go through that when handling "assign" semantics. This way, we
can use CONSTANT_TRANSLATION again for these instructions, or a simpler
decision process between Assign and LookThrough.
The actually undoes a small change made earlier when we stopped looking
through `init_existential_value` instructions. Now we do when there are
no isolated conformances.
Better match the style of SILIsolationInfo by moving the code for determining
SILIsolationInfo from conformances or dynamic casts to existentials into
static `getXYZ` methods on SILIsolationInfo.
Other than adding an assertion regarding disconnected regions, no
intended functionality change.
When we introduce isolation due to a (potential) isolated conformance,
keep track of the protocol to which the conformance could be
introduced. Use this information for two reasons:
1. Downgrade the error to a warning in Swift < 7, because we are newly
diagnosing these
2. Add a note indicating where the isolated conformance could be introduced.
(cherry picked from commit 02c34bb830)
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
(cherry picked from commit 62770ff2d7)
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://155059418
Cherry pick of #82370 to 6.2 branch.
---
* **Explanation**: Resolves an issue where sema is flagging inout
expressions 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.
* **Risk**: Low. It allows inout expressions in one additional context.
* **Testing**: Tested by lit tests, including new tests for the newly
allowed expression.
* **Issue**: rdar://153840234
* **Reviewer**: @slavapestov
* **Main branch PR**: https://github.com/swiftlang/swift/pull/82370
SILGen already has an exception for this from -enable-actor-data-race-checks,
so there's no need for it, and it causes problems in actor inits.
Fixes rdar://155239032
Forming an isolated conformance to a SendableMetatype-inherting
protocol opens up a soundness hole any time the conformance is used.
Reword the recently-introduced diagnostic for this case and promote it
to an error (except when it's preconcurrency).
Fixes rdar://154808002.
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.
C code is highly likely to want to use pointers as references between dependent
structs, and we would like to be able to readily map these to lifetime-dependent
Swift values. Making C types addressable-for-dependencies ensures that any function
producing a dependency on such a value receives a stable in-memory address for that
value, allowing borrows and inout accesses to always be representable as pointers.
rdar://153648393
`LifetimeDescriptor::getName()` can crash if the descriptor had a `self`.
Replace with `LifetimeDescriptor::getString()`
(cherry picked from commit 6d0a6d2760)
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
