Their definition is fully visible to clients to be copied into them, and there isn't necessarily
a symbol for the property descriptor in the defining module, so it isn't necessary or desirable to
try to use a property descriptor with them. Trying to reference the descriptor leads to missing
symbol errors at load time when trying to use keypaths with older versions of the defining dylib,
which goes against the purpose of `@_alwaysEmitIntoClient` meaning "no ABI liabilities for the
defining module". Fixes rdar://94049160.
`RelabelArguments` cannot possibly diagnose this issue because there
are no argument lists in this case. Let's report contextual mismatch
instead.
Resolves: https://github.com/apple/swift/issues/59058
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
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
