Preserving sugar if we have type variables uses way too much memory.
Canonicalize these substitution maps for now, as a (temporary?) workaround.
In the future, if we decide preserving sugar is more important than a
few dozen Mb of memory usage, we can also bump the arena memory limit,
instead.
Fixes rdar://166237860.
Fixes rdar://165863647.
Otherwise if the member lookup gets simplified immediately and we
have a recursive dynamic member lookup we will crash since we wouldn't
have introduced the corresponding applicable function constraint.
rdar://164321858
We don't do memory lifetime analysis for this peephole optimization.
Therefore we can't risk sinking instructions with address operands out of the addressed memory's lifetime.
For example:
```
%3 = mark_dependence %2 on %1 : $*T // must not be moved after the destroy_addr
destroy_addr %1
```
Fixes a verifier crash
rdar://166240751
In #65125 (and beyond) `matchTypes`, has logic to attempt to wrap an
incoming parameter in a tuple under certain conditions that might help
with type expansion.
In the case the incoming type was backed by a `var`, it would be wrapped
by an `LValueType` then be subsequently mis-diagnosed as not-a-tuple.
More details in #85924 , this this is also the cause of (and fix for)
#85837 as well...
We were only previously doing this check when we had a typedef,
because that is the scenario where we encountered this issue.
This patch moves the check closer to where we would actually instantiate
the template, so that these cases can be stopped in more situations.
This ensures that in cases like the following:
+func testNoncopyableNonsendableStructWithNonescapingMainActorAsync() {
+ let x = NoncopyableStructNonsendable() <=========
+ let _ = {
+ nonescapingAsyncClosure { @MainActor in
+ useValueNoncopyable(x) // expected-warning {{sending 'x' risks causing data races}}
+ // expected-note @-1 {{task-isolated 'x' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses}}
+ }
+ }
+}
We emit the diagnostic on the use instead of the <=====.
rdar://166347485
I have noticed over time when working on the command line, we often times
highlight too large of an expression due to the locations provided to us by
earlier parts of the compiler. This isn't technically necessary and the
following doesn't look nice... so remove it.
```
test5.swift:171:16: error: sending 'x' risks causing data races [#SendingRisksDataRace]
169 | let _ = {
170 | nonescapingAsyncUse { @MainActor in
171 | _ _ _ _ _u_s_e_V_a_l_u_e_(_x_)
| |- error: sending 'x' risks causing data races [#SendingRisksDataRace]
| `- note: task-isolated 'x' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
172 | }
173 | }
```
We may see undef closure captures in ClosureLifetimeFixup since
it is a mandatory pass that runs on invalid code as well.
This could sometimes hang the compiler while running `insertDeallocOfCapturedArguments`
in release builds.
This change adds a bailout when we see an undef closure capture to avoid running into this issue.
Enables upcoming features that aim to provide a more approachable path to Swift Concurrency:
- `DisableOutwardActorInference`
- `GlobalActorIsolatedTypesUsability`
- `InferIsolatedConformances`
- `InferSendableFromCaptures`
- `NonisolatedNonsendingByDefault`
Resolves: rdar://166244164
Impact for an unknown property access was frequently higher than other options
on ambiguous selections, by 3 to 5 points, causing fix selections that were
farther away and frequently noted to be in accurate. This commit lowers the
impact to be in a similar range to other fixes and this causes property accesses
to be selected more proprotionaly.
In the existing test suite, this changed the diagnostic only in the case of
protocol composition, which was also discovered to be a flawed binding lookup.
Tests added for the property lookup, tests updated for protocol composition
(Including correcting a likely error in a test specification)
Introduce a cache that helps cutting the recursion when we process a
type that we already visited before but did not finish processing yet.
Fixes#85361
rdar://164153038
See https://github.com/llvm/llvm-project/pull/161403.
These `isa` calls with a `CanType` no longer compile with LLVM next
because the implementation now unfolds directly to `CastInfo` calls
rather than non-variadic `isa` calls that resolve to our partial
specializations here:
e293876e4f/include/swift/AST/Type.h (L600)
We should partially specialize `CastInfo` instead of `isa` et al. For
now, just use the non-variadic `isa`.
The underlying C++ code expects a non-null `Instruction*` or `SILArgument*` pointer, and
most of the contextual information in a verifier error is derived from these arguments,
so it doesn't really make sense for the Swift level interface to present these arguments
as optional.
