Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
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)
rdar://155596073 Task executors execution may not always hop as expected
I'm investigating a fix here as we speak, but disabling the specific piece of the test while we work on it.
Explanation: We the generated reverse interop headers to be valid C++,
so every declaration coming from an Obj-C module should be behind an
ifdef. Unfortunately, we do not always have this information but we do
know that our frameworks contain Obj-C code. So this PR makes sure every
entity coming from our frameworks are behind ifdef.
Issues: rdar://152836730
Original PRs: #83002
Risk: Low, the change is narrow and straightforward.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Under discussion as part of an amendment to SE-0466, limit default main
actor inference so it doesn't apply to a nested type within a
nonisolated type.
Specifically for 6.2, we are making optimize hop to executor more conservative
around caller isolation inheriting functions. This means that we are:
1. No longer treating calls to caller isolation inheriting functions as having a
hop in their prologue. In terms of this pass, it means that when determining
dead hop to executors, we no longer think that a caller isolation inheriting
function means that an earlier hop to executor is not required.
2. Treating returns from caller isolation inheriting callees as requiring a
hop. The reason why we are doing this is that we can no longer assume that our
caller will hop after we return.
Post 6.2, there are three main changes we are going to make:
* Forward Dataflow
Caller isolation inheriting functions will no longer be treated as suspension
points meaning that we will be able to propagate hops over them and can assume
that we know the actor that we are on when we enter the function. Practically
this means that trees of calls that involve just nonisolated(nonsending) async
functions will avoid /all/ hop to executor calls since we will be able to
eliminate all of them since the dataflow will just propagate forward from the
entrance that we are already on the actor.
* Backwards Dataflow
A caller isolation inheriting call site will still cause preceding
hop_to_executor functions to be live. This is because we need to ensure that we
are on the caller isolation inheriting actor before we hit the call site. If we
are already on that actor, the hop will be eliminated by the forward pass. But
if the hop has not been eliminated, then the hop must be needed to return us to
the appropriate actor.
We will also keep the behavior that returns from a caller isolation inheriting
function are considered to keep hop to executors alive. If we were able to
propagate to a hop to executor before the return inst with the forward dataflow,
then we know that we are guaranteed to still be on the relevant actor. If the
hop to executor is still there, then we need it to ensure that our caller can
treat the caller isolation inheriting function as a non-suspension point.
rdar://155905383
(cherry picked from commit b3942424c8)
Specifically, we write a string out like:
sil [isolation "$REPRESENTATION OF ISOLATION"] @function : $@convention(thin) ...
The idea is that by using a string, we avoid parsing issues of the isolation and
have flexibility. I left in the way we put isolation into the comment above
functions so I did not break any tests that rely on it. I also made it so that
we only accept this with sil tests that pass in the flag
"sil-print-function-isolation-info". I am going to for the next release put in a
full real implementation of this that allows for actor isolation to become a
true first class citizen in SIL. But for now this at least lets us write tests
in the short term.
Since this is temporary and behind a flag, I did not add support for
serialization since this is just for writing textual SIL tests.
(cherry picked from commit ee3027c2ca)
Conflicts:
lib/SIL/Parser/ParseSIL.cpp
With `NonisolatedNonsendingByDefault` an explicit `nonisolated`
attribute in declaration context is inferred to mean `nonisolated(nonsending)`
and it should be printed as such in interface files and other places.
The inference logic that did didn't remove the original attribute
which meant that it would be printed twice i.e.
`nonisolated nonisolated(nonsending) func test() async` which is
incorrect and would fail swift interface validation.
Resolves: rdar://155847011
(cherry picked from commit b519c07428)
tryJoinIfDestroyConsumingUseInSameBlock replaces a copy with its operand
when there is no use of the copy's operand between the copy's forwarded consuming use
and the copy operand's destroy in the same block. It is illegal to do this transformation
when there is a non-consuming use of the copy operand after the forwarded consuming use of the copy.
The code checking this illegal case was not considerin the case where the consuming use of the copy
was in the same instruction as the non-consuming use of the copy operand.
rdar://154712867
Global actor kind also appends type offset that indicates what
global actor to use with the type. All of the isolation kinds
should be placed above it to make sure that there is never a
clash when i.e. `MainActor` is serialized as id `1`.
Resolves: rdar://153487603
(cherry picked from commit ace6f738ba)
Completion can end up calling into pre-checking multiple times in
certain cases, make sure we don't attempt to fold a SequenceExpr
multiple times since its original AST is in a broken state
post-folding. Instead, just return the already-folded expression.
rdar://133717866
In order to accommodate case bodies with multiple case labels, the AST
represents the bindings in each pattern as a distinct declaration from
the matching binding in the case body, and SILGen shares the variable
representation between the two declarations. That means that the two
declarations also need to be able to share an addressable representation.
Add an "alias" state to the addressable buffer data structures so that
we can refer back to the original case label var decl when the case body
var decl is brought into scope, so that accesses through either decl
properly force the addressable representation.
Fixes rdar://154543619.
When checking whether a capture of a metatype is Sendable, we had an
incomplete and incorrect check for SendableMetatype conformance.
Replace that with the proper "prohibits isolated conformances" check
on the generic signature, which matches what we do on the caller side.
Fixes issue #82905 / rdar://155399531.
