I tried to make them shorter and standardized on "; later accesses could race"
as the mark on a diagnostic that the problem was that a race was occuring
(before we had several small different variations).
Before the previous patch, we were just getting lucky on macOS due to UB. Now
that the UB is fixed, we correctly crash without this commit since we were not
pattern matching the simple case of a local value that was transferred and used
later.
The specific semantics is if we assign into a transferring parameter's field,
then we "merge" src's value into the transferring parameter, so we
conservatively leave the region of the transferring parameter alone. If we
assign over the entire transferring parameter, we perform an assign fresh since
any value that used to be in the transferring parameter cannot reference
anything in its new value since they are all gone.
NOTE: This does not handle yet assignment into transferring parameters. In the
next commit, I am going to teach the checker that assigning into such a
parameter is a transfer.
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
Because we're mentioning the type in a macro and it gets used elsewhere,
we need to be explicit that the type is inside threading_impl.
rdar://121122202
Most clients only want to set one of the two
parameters, split it into `setPattern` and
`setInitContext` (the latter of which now
handles calling `setBinding`).
Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
Switch from promising a DeclContext to a
PatternBindingInitializer.
This has a couple of benefits:
- It eliminates a few places where we were force
`cast`'ing to PatternBindingInitializer.
- It improves the clarity of what's being stored,
it's not whatever the parent context of the
initializer is, it's specifically the
PatternBindingInitializer context if it exists.
rdar://121071710
Currently it uses builtin integers, which round up to the next power of 2, which is not what we want here. Instead it should use builtin vectors of uint8 and a number of elements equal to the stride in bytes.
Introduce a new expression macro that produces an value of type
`(any AnyActor)?` that describes the current actor isolation. This
isolation will be `nil` in non-isolated code, and refer to either the
actor instance of shared global actor in other cases.
This is currently behind the experimental feature flag
OptionalIsolatedParameters.
