Instead of doing one or two non-iterative BackwardReachability runs,
do a single run of IterativeBackwardReachability. During that, pause
after discovery/local dataflow and use VisitBarrierAccessScopes to
determine which end_access instructions in the discovered region are
barriers. Add those instructions as kills to the dataflow. Finally run
the global dataflow.
Enables SSADestroyHoisting to hoist destroys over loops.
Addresses a correctness issue where access scopes which were open at
barrier blocks were not promoted to barriers, resulting in destroy_addrs
getting hoisted into unrelated access scopes.
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
Any substring of `target_triple` is allowed as a feature (when used in
REQUIRES/UNSUPPORTED/XFAIL) in `lit.py`. This is what allows eg. `XFAIL:
linux` even though `linux` isn't listed as an available feature.
`TARGET_TRIPLE` was renamed to `LLVM_TARGET_TRIPLE` upstream, so rename
it here as well. Going forward we should remove `target_triple` entirely
and use our `OS=...` features instead.
The following issues no longer reproduce on `main` and had reduced reproducers. Add them to the test suite.
- SR-12977
- SR-14691
- SR-15113
- rdar://63063279
- rdar://64227741
- rdar://69813796
- rdar://85609548
We would like to leave room in the language for `some` types in existential
constraints a la `any P<some Q>` to resolve as a part of the requirement
signature of a future generalized existential type. To that end, usages of
`some` types nested anywhere in the arguments of an existential will fail to
resolve.
rdar://92758884
The characters used before were in the private-use section had surrogate
chars. This led to issues with some python utf8 decoder implementations
resulting in the error
```
UnicodeEncodeError: 'utf-8' codec can't encode characters in position
13-20: surrogates not allowed
```
This uses more normal utf8 characters that should hopefully work
everywhere while still exhibiting issues decoding to ascii.
`EnumElement` patterns with optional base type do member lookup
on both optional type and its wrapped type but do not synthesize
`~=` operator call.
Resolves: rdar://92327807
You would think that superclass + conformances form a DAG. You are wrong!
We can achieve a circular supertype hierarcy with
```swift
protocol Proto : Class {}
class Class : Proto {}
```
USRBasedType is not set up for this. Serialization of code completion results from global modules can't handle cycles in the supertype hierarchy
because it writes the DAG leaf to root(s) and needs to know the type offsets. To get consistent results independent of where we start
constructing USRBasedTypes, ignore superclasses of protocols. If we kept track of already visited types, we would get different results depending on
whether we start constructing the USRBasedType hierarchy from Proto or Class.
Ignoring superclasses of protocols is safe to do because USRBasedType is an under-approximation anyway.
rdar://91765262
Multi-statement closure + simd perf test-case still (albeit very
rarely) fails, so let's remove `/ 4` in attempt to prevent that
happening.
Resolves: rdar://92025732
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
Previously, the AbstractionPattern that was used for the value
"returned" (i.e. via a completion handler) from ObjC mostly (but not
quite always) was "type".
The generated completion handler correctly (because this is required in
order to call _resumeUnsafeContinuation) reabstracted the block (e.g.
from @convention(block) to @substituted <T> () -> @out T for <()>). The
callee of the ObjC function, however, loaded the function from the block
as if it were not reabstracted (e.g. () -> ()).
On most platforms, that happened to work. On arm64e, that difference in
types caused in a difference in pointer signing, resulting in a failure
at runtime.
rdar://85526879
rdar://85526916
When construction call is rewritten into a tuple conversion,
rewriter has to make sure that AST types are reset otherwise
it would end up with types set by `packIntoImplicitTupleOrParen`
which could contain l-values.
Resolves: rdar://90366182
