Specifically:
I changed the main error message to focus on the closure and that the closure
is being accessed concurrently.
If we find that we captured a value that is the actual isolation source, we
emit that the capture is actually actor isolated.
If the captured value is in the same region as the isolated value but is not
isolated, we instead say that the value is accessible from *-isolated code or
code within the current task.
If we find multiple captures and we do not which is the actual value that was
in the same region before we formed the partial apply, we just emit a note on
the captures saying that the closure captures the value.
I changed the diagnostics from using the phrase "task-isolated" to use some
variant of accessible to code in the current task.
The idea is that in all situations we provide a breadcrumb that the user can
start investigating rather than just saying that the closure is "task-isolated".
From a preconcurrency perspective, I made it so that we apply the preconcurrency
behavior of all of the captures. This means that if one of the captures is
preconcurrency, we apply the preconcurrency restriction to the closure. This is
one step towards making it so that preconcurrency applies at the region level...
we just are not completely there yet.
rdar://133798044
Specifically, this API has some hard edges where instead of just returning an
invalid value to signal that we do not have self, we assert or return something
bogus. This commit just fixes our usage of that API to be correct.
rdar://132545626
We only use typed diagnostics if we are unable to pattern match a name for a
SILValue. Since we generally do this (in most of our tests we do for instance),
it is hard to test this. So I put in an option here that is enabled only in
asserts that forces the diagnostic emitter to emit the typed diagnostic by
forcing a name inference failure. This then allows me to write an asserts only
test that validates the behavior of the typed diagnostics since I can guarantee
the typed diagnostics will run.
The changes to allow for partial consumption unintentionally also allowed for
`self` to be consumed as a whole during `deinit`, which we don't yet want to
allow because it could lead to accidental "resurrection" and/or accidental
infinite recursion if the consuming method lets `deinit` be implicitly run
again. This makes it an error again. The experimental feature
`ConsumeSelfInDeinit` will allow it for test coverage or experimentation
purposes. rdar://132761460
When checking whether an instruction is contained in a liveness
boundary, a pointer to a DeadEndBlocks instance must always be passed.
When the pointer is null, it is only checked that the instruction occurs
within the direct live region. When the pointer is non-null, it is
checked whether the instruction occurs within the region obtained by
extending the live region up to the availability boundary within
dead-end regions that are adjacent to the non-lifetime-ending portion of
the liveness boundary.
This is just moving up the declaration in the chain of dependencies so that I
can write logic in PartitionUtils.h using it. I also added entrypoints to lookup
the ReprensetativeValue for our various emitters.
This reverts commit b63781f7ba.
We found some cases where due to malformed IR that we allow through due to
either us compiling for strict-concurrency=complete+swift-5 or swift-6 +
preconcurrency, that we can actually have actor isolation mismatch. I am going
to in a subsequent commit add a better phrasing here. But for now, just undo the
conversion from error -> warning.
rdar://131757602
This shows an actual issue with the compiler where semantically we should crash.
Rather than crashing (due to the broken invariants), we emit this error so that
the user gets a nice error message at the problem place and can work around it
instead of just getting a mysterious crash.
Previously, we were making this a warning in swift 5 mode... but given the
issues, it makes sense to emit an error diagnostic so we get the feedback and
the user cannot ship the code.
rdar://131482934
Otherwise, we will assume that an async let autoclosure infers isolation from
its DeclContext... which we do not want. An async let autoclosure should always
be nonisolated + sending.
The diagnostic change that I mentioned in the header is that we were emitting
unfortunate "sending task or actor isolated could result in races" error. I
eliminated this by adding a new diagnostic for transfer non transferrable errors
happening in autoclosures. So now we emit this:
```swift
func asyncLetInferAsNonIsolated<T : Actor>(
isolation actor: isolated T
) async throws {
async let subTask: Void = {
await useValueAsyncNoReturnWithInstance(self, actor)
// expected-warning @-1:47 {{sending 'self' risks causing data races}}
// expected-note @-2 {{sending 'actor'-isolated 'self' into async let risks causing data races between nonisolated and 'actor'-isolated uses}}
}()
await subTask
```
I also noticed that we did not have enough test cases for autoclosures in
general so I also added a bunch of tests just so we can see what the current
behavior is. I think there are a few issues therein (I believe some may have
been reported due to '??').
rdar://130151318
This is triggered by the test case in the next commit. The problem is anonymous
closures can be passed here and they do not have a ValueDecl so there isn't a
decl for us to use.
Otherwise IRGen would crash.
It needs a bit of work to support alloc_box of generic non-copyable structs/enums with deinit, because we need to specialize the deinit functions, though they are not explicitly referenced in SIL.
Until this is supported, give an error in such cases.
Fixes a compiler crash in IRGen
rdar://130283111
