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 | }
```
All linux and Android CI show this being repeated many times, eg when
[building the Docc binary on the linux
CI](https://ci.swift.org/job/swift-PR-Linux-smoke-test/24247/consoleText):
```
"/home/build-user/build/buildbot_linux/unified-swiftpm-build-linux-x86_64/x86_64-unknown-linux-gnu/release/docc.build/main.swift.o" "-lswiftObservation" ... repeated many times ... "-lswiftObservation" "-lswiftCore"
```
A previous commit introduced the usage of buildContextManglingForSymbol
in buildContextDescriptorMangling, which was not quite correct, since
type nodes needed extra handling, which was done in the other version of
buildContextDescriptorMangling. This patch factors out the handling of
building context descriptors mangling from symbols, and updates both
call sites to use the new function instead.
rdar://165950673
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
If the property isn't memberwise initializable we need to emit its
initial value and call the init accessor. This currently isn't necessary
since all init accessor properties are included in the memberwise
initializer, but the following commit will change this.
Currently `init` accessors are always memberwise initialized, but I'm
planning on changing that. As such we need to make sure we record
the `init` accessor regardless of whether it is included in the memberwise
init.
This serves as the backing request for both InitAccessorPropertiesRequest
and MemberwiseInitPropertiesRequest, ensuring the former does not
care about the init accessor is included in the memberwise initializer.
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
If we didn't find an extension result, try again disregarding
invertible requirements since `demangleGenericSignature` won't
include them. This is just meant to be a quick low risk fix that we
can cherry-pick, the proper fix here is to delete all this logic and
just return the nominal along with the ABI module name to filter
lookup results.
rdar://165639044
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
LLVM no longer tail-calls this on x86_64, so we do not need an autorelease pool. Remove it for i386 as well as that is no longer a target for ObjC interop builds.
