If back-deploying prior to the introduction of name mangling and
runtime support for invertible constraints (~Copyable, ~Escapable),
don't use mangled names to access metadata. The code already existed
for this, but had a carve-out that still used mangled names for
standard library types that have always existed but got generalized to
support non-copyable & non-escapable types.
Tweak that carve-out to not apply to types like Span that come from a
back-deployment library. Fixes crashes when using metadata for Span et
al on older platforms.
Fixes rdar://155639204.
This patch changes RemoteAbsolutePointer to store both the symbol and
the resolved address. This allows us to retire some ugly workarounds
to deal with non-symbolic addresses and it fixes code paths that would
need these workarounds, but haven't implemented them yet (i.e., the
pack shape handling in the symbolicReferenceResolver in MetadatyaReader.
Addresses parts of rdar://146273066.
rdar://153687085
(cherry picked from commit 9381a54c67)
(cherry picked from commit a6eafcb311)
The compiler shouldn't accept mismatch in explicit isolation attributes
because it could lead to incorrect isolation selection.
Resolves: rdar://155589753
(cherry picked from commit a9373c0f3f)
The reason why this failed is that concurrently to @xedin landing
79af04ccc4, I enabled
NonisolatedNonsendingByDefault on a bunch of other tests. That change broke the
test and so we needed to fix it.
This commit fixes a few issues that were exposed:
1. We do not propagate nonisolated(nonsending) into a closure if its inferred
context isolation is global actor isolated or if the closure captures an
isolated parameter. We previously just always inferred
nonisolated(nonsending). Unfortunately since we do not yet have capture
information in CSApply, this required us to put the isolation change into
TypeCheckConcurrency.cpp and basically have function conversions of the form:
```
(function_conversion_expr type="nonisolated(nonsending) () async -> Void"
(closure_expr type="() async -> ()" isolated_to_caller_isolation))
```
Notice how we have a function conversion to nonisolated(nonsending) from a
closure expr that has an isolation that is isolated_to_caller.
2. With this in hand, we found that this pattern caused us to first thunk a
nonisolated(nonsending) function to an @concurrent function and then thunk that
back to nonisolated(nonsending), causing the final function to always be
concurrent. I put into SILGen a peephole that recognizes this pattern and emits
the correct code.
3. With that in hand, we found that we were emitting nonisolated(nonsending)
parameters for inheritActorContext functions. This was then fixed by @xedin in
With all this in hand, closure literal isolation and all of the other RBI tests
with nonisolated(nonsending) enabled pass.
rdar://154969621
(cherry picked from commit 648bb8fe30)
If a function has lifetime dependencies, disable FSO's dead param optimization. Dead params maybe dependency sources and we should not delete them. It is also problematic to dead code params that are not dependency sources, since lifetime dependent sources are stored as indices and deleting dead parameters will require recomputation of these indices.
When synthesizing code for Codable conformances involving unsafe types,
make sure to wrap the resulting expressions in "unsafe" when strict memory safety is enabled.
Tweak the warning-emission logic to suppress warnings about spurious
"unsafe" expressions when the compiler generated the "unsafe" itself,
so we don't spam the developer with warnings they can't fix. Also make
the checking for other suppression considerations safe when there are
no source locations, eliminating a potential assertion.
Fixes rdar://153665692.
The `$generator` variable we create for the async for..in loop is
`nonisolated(unsafe)`, so ensure that we generate an `unsafe`
expression when we use it. This uncovered some inconsistencies in how
we do `unsafe` checking for for..in loops, so fix those.
Fixes rdar://154775389.
(cherry picked from commit 35628cb503)
The logic here was unnecessary, the SourceRange gets converted to a
CharSourceRange in the function being called, which handles raw
identifiers correctly. 6.2-only since this is already fixed on main.
rdar://152273926
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
