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...
