Freshly built libc++ introduces issues when building `swift-build`:
```
Undefined symbols for architecture arm64:
"std::__1::__hash_memory(void const*, unsigned long)", referenced from:
(anonymous namespace)::CAPIBuildDB::buildUpKeyCache(std::__1::vector<llbuild::core::KeyType, std::__1::allocator<llbuild::core::KeyType>>&) in BuildDB-C-API.cpp.o
_llb_build_key_make in BuildKey-C-API.cpp.o
_llb_build_key_make_command in BuildKey-C-API.cpp.o
_llb_build_key_make_custom_task in BuildKey-C-API.cpp.o
_llb_build_key_make_custom_task_with_data in BuildKey-C-API.cpp.o
_llb_build_key_make_directory_contents in BuildKey-C-API.cpp.o
_llb_build_key_make_filtered_directory_contents in BuildKey-C-API.cpp.o
...
ld: symbol(s) not found for architecture arm64
```
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
This introduces a new substitution for use in the CAS tests. The plain
variant of the target frontend invokes the tool with the variant target
triple and resource dir only. This allows us to properly invoke the
frontend for the CAS tests.
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
These were mostly bugs with code of the following form:
```
if uint64Value < (... literal expression ...)
```
Swift's comparison operators allow their left- and right-hand sides to be of
different widths. This in turn means that the literal expression above
typically gets typechecked by default as a plain `Int` or `UInt` expression.
In a number of cases, this led to truncation on platforms where `Int` is
not 64 bits.
In particular, this seems to fix tests on wasm32.
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 | }
```
Ensure that we account for file system arc separators and extensions by
using the LLVM functions rather than trying to simply do string
matching. This allows us to properly handle inputs on Windows.
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`.
