Repurpose mangling operator `Y` as an umbrella operator that covers new attributes on function types. Free up operators `J`, `j`, and `k`.
```
async ::= 'Ya' // 'async' annotation on function types
sendable ::= 'Yb' // @Sendable on function types
throws ::= 'K' // 'throws' annotation on function types
differentiable ::= 'Yjf' // @differentiable(_forward) on function type
differentiable ::= 'Yjr' // @differentiable(reverse) on function type
differentiable ::= 'Yjd' // @differentiable on function type
differentiable ::= 'Yjl' // @differentiable(_linear) on function type
```
Resolves rdar://76299796.
Introduce `@concurrent` attribute on function types, including:
* Parsing as a type attribute
* (De-/re-/)mangling for concurrent function types
* Implicit conversion from @concurrent to non-@concurrent
- (De-)serialization for concurrent function types
- AST printing and dumping support
* Use the correct Python executable to match LLDB
The linux-fatal-backtrace script needs to run with an LLDB
module loaded into Python. This in turn requires that the
test be run with the exact same Python version as was used
by LLDB (not just the same Python module directory). This
can get confused on systems with multiple versions of Python
installed.
This replaces `lldb-python-path` (the Python module directory path)
with `lldb-python` (which is the correct Python version run with
the LLDB path). This should ensure that this test is always
run with the same Python version and module that LLDB used.
* Use consistent braces for the lldb-python substitution
* Use os.path utilities to dissect paths
* Allow `python3` as a path identifier
Previous code required a decimal point before it would
recognize a path component as a Python version identifier,
so it would accept `python2.7` but not `python3`.
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
Previously, when NDEBUG was not defined, the allocations made for value
metadata records were filled with 0xAA bytes. Here, that behavior is
both expanded to all metadata records and enabled in release builds when
the environment variable SWIFT_DEBUG_ENABLE_MALLOC_SCRIBBLE is set.
In #32137 direct environment variable parsing was introduced, the
availability of which is branched by a preprocessor symbol (`ENVIRON`)
if the environment is available directly on the platform, or if getenv
must be used.
The message expectation in the unit test in the however diverged on the
non-`ENVIRON` branch, causing a unit test failure. This PR fixes the
expectation, but also, while we're here, OpenBSD supports the `ENVIRON`
branch anyway.
There are a few environment variables used to enable debugging options in the
runtime, and we'll likely add more over time. These are implemented with
scattered getenv() calls at the point of use. This is inefficient, as most/all
OSes have to do a linear scan of the environment for each call. It's also not
discoverable, since the only way to find these variables is to inspect the
source.
This commit places all of these variables in a central location.
stdlib/public/runtime/EnvironmentVariables.def defines all of the debug
variables including their name, type, default value, and a help string. On OSes
which make an `environ` array available, the entire array is scanned in a single
pass the first time any debug variable is requested. By quickly rejecting
variables that do not start with `SWIFT_`, we optimize for the common case where
no debug variables are set. We also have a fallback to repeated `getenv()` calls
when a full scan is not possible.
Setting `SWIFT_HELP=YES` will print out all available debug variables along with
a brief description of what they do.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
Two tests are currently failing with
dyld: lazy symbol binding failed: Symbol not found: _objc_opt_self
Expected in: /usr/lib/libobjc.A.dylib
dyld: Symbol not found: _objc_opt_self
Expected in: /usr/lib/libobjc.A.dylib
Here, they are disabled for now.
rdar://problem/61345988
When constructing the metadata for a type Gen<T : Super>
where Super is a superclass constraint, the generic argument K at which
the metadata for Gen is being instantiated is verified to be a subclass
of Super via _checkGenericRequirements.
Previously, that check was done using swift_dynamicCastMetatype. That
worked for the most part but provided an incorrect answer if the
metadata for K was not yet complete. These classes are incomplete more
often thanks to __swift_instantiateConcreteTypeFromMangledNameAbstract.
That issue occurred concretely in the following case:
Framework with Library Evolution enabled:
open class Super { ... }
public struct Gen<T : Super> {
}
Target in a different resilience domain from that framework:
class Sub : Super {
var gen: Gen<Sub>?
}
Here, the mechanism for checking whether the generic argument K at which
the metadata for Gen is being instantiated handles the case where K's
metadata is incomplete. At worst, every superclass name from super(K)
up to Super are demangled to instantiate metadata. A number of faster
paths are included as well.
rdar://problem/60790020
This one’s screwily specific--if you have:
* a private generic type,
* with a nested generic type in it,
* and the nested type conforms to a protocol with an associated type,
* and that associated type’s witness is a generic type,
* and some of the witness type’s generic parameters are generic parameters of the nested type,
demangling would fail. The problem is that the substitution machinery in the runtime would consider there to be three, not two, generic context depths involved. Depth 1, which should correspond to the nested type, would instead have no generic parameters. The fix is to skip over depths with zero generic parameters.
Fixes <rdar://problem/47773183>.
1) Enable tests that use `import Dispatch` on Linux. Add substitution
`%import-libdispatch` that needs to be used for all cross-platform
tests (i.e., tests that are intended to be run on other platforms
than Darwin) that do `import Dispatch` or enable thread sanitizer.
2) Make sure as many existing Dispatch and TSan tests as possible run on
Linux. Mark tests that would require substantial work with
`UNSUPPORTED: OS=linux-gnu`.
3) Add integration-style Swift test that shows that TSan finds a simple
race when using `Dispatch.async` incorrectly. A more complete test
suite for TSan's libdispatch support lives on the LLVM/compiler-rt
side.
rdar://problem/49177535
