This is kind of complicated, because an enum can be trivial for one case and not trivial for another case. We need to check at which parts of the function we can prove that the enum does (or could) have a trivial case. In such a branch, it's not required in SIL to destroy the enum location.
Also, document the rules and requirements for enum memory locations in SIL.rst.
rdar://73770085
Plumb generic signatures through the codegen for invoking foreign APIs as async, so that we
correctly handle APIs declared on ObjC lightweight generic classes. rdar://74361267
Add the following new mangling rules.
```
global ::= from-type to-type 'TJO' AUTODIFF-FUNCTION-KIND // autodiff self-reordering reabstraction thunk
global ::= from-type 'TJS' AUTODIFF-FUNCTION-KIND INDEX-SUBSET 'p' INDEX-SUBSET 'r' INDEX-SUBSET 'P' // autodiff linear map subset parameters thunk
global ::= global to-type 'TJS' AUTODIFF-FUNCTION-KIND INDEX-SUBSET 'p' INDEX-SUBSET 'r' INDEX-SUBSET 'P' // autodiff derivative function subset parameters thunk
```
Example:
```console
$s13TangentVector16_Differentiation14DifferentiablePQzAaDQy_SdAFIegnnnr_TJSdSSSpSrSUSP ---> autodiff subset parameters thunk for differential from @escaping @callee_guaranteed (@in_guaranteed A._Differentiation.Differentiable.TangentVector, @in_guaranteed B._Differentiation.Differentiable.TangentVector, @in_guaranteed Swift.Double) -> (@out B._Differentiation.Differentiable.TangentVector) with respect to parameters {0, 1, 2} and results {0} to parameters {0, 2}
$sS2f8mangling3FooV13TangentVectorVIegydd_SfAESfIegydd_TJOp ---> autodiff self-reordering reabstraction thunk for pullback from @escaping @callee_guaranteed (@unowned Swift.Float) -> (@unowned Swift.Float, @unowned mangling.Foo.TangentVector) to @escaping @callee_guaranteed (@unowned Swift.Float) -> (@unowned mangling.Foo.TangentVector, @unowned Swift.Float)
```
Resolves rdar://72666310 / SR-13508.
Also fix a bug in `AutoDiffFunction` mangling where the original may be a global that contains more than 1 node (rdar://74151229 / SR-14106).
* rename -sil-print-only-function to -sil-print-function and -sil-print-only-functions to -sil-print-functions
* to print single functions, don't require -Xllvm -sil-print-all. It's now sufficient to use e.g. -Xllvm -sil-print-function=<f>
But it's still possible to select functions with -sil-print-function(s) for other print options, -sil-print-after.
Compiler:
- Add `Forward` and `Reverse` to `DifferentiabilityKind`.
- Expand `DifferentiabilityMask` in `ExtInfo` to 3 bits so that it now holds all 4 cases of `DifferentiabilityKind`.
- Parse `@differentiable(reverse)` and `@differentiable(_forward)` declaration attributes and type attributes.
- Emit a warning for `@differentiable` without `reverse`.
- Emit an error for `@differentiable(_forward)`.
- Rename `@differentiable(linear)` to `@differentiable(_linear)`.
- Make `@differentiable(reverse)` type lowering go through today's `@differentiable` code path. We will specialize it to reverse-mode in a follow-up patch.
ABI:
- Add `Forward` and `Reverse` to `FunctionMetadataDifferentiabilityKind`.
- Extend `TargetFunctionTypeFlags` by 1 bit to store the highest bit of differentiability kind (linear). Note that there is a 2-bit gap in `DifferentiabilityMask` which is reserved for `AsyncMask` and `ConcurrentMask`; `AsyncMask` is ABI-stable so we cannot change that.
_Differentiation module:
- Replace all occurrences of `@differentiable` with `@differentiable(reverse)`.
- Delete `_transpose(of:)`.
Resolves rdar://69980056.
Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK
22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a
bunch of simplification that's now possible.
Swift uses `ar s`, but LLVM does an `ar` and `ranlib` pass separately. To
work around the platform binutils bug, you should use the LLVM version of
both these tools, not just `ar`.
Add @concurrent to SIL function types, mirroring what's available on
AST function types. @concurrent function types will have by-value
capture semantics.
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
The guide as written results in lots of repositories being placed as siblings to `swift-project`, instead of inside of it. This also results in the `build` directory being a sibling. Changing the clone to the `swift` directory fixes this.
When making debug builds, `Decl.cpp` compiles with a large number of ELF
section headers; including randomdata sections as normally included by
the platform for security purposes, this may in reality exceed the ELF
limit of `SHN_LORESERVE`.
In this case, the ELF header field containing the number of section
headers, `e_shnum`, is set to 0 and the real number of section headers
is stored elsewhere. However, when an object file has no section
headers, this field is also set to 0.
OpenBSD uses the GNU binutils by default. These binutils do not handle
the case when `e_shnum` is 0, and assume that the object file has no
section headers. But the only tool that counts is the static archive
tool `ar`. When creating the archive index, `ar` encounters `Decl.cpp.o`
as part of `libswiftAST.a`, notes that `e_shnum` is 0, and skips the
object file entirely, presumably because it thinks the object file has
no section headers and therefore no symbols. This leads the linker to
assume that symbols in `Decl.cpp.o` are not part of `libswiftAST.a`,
when in fact they are.
The LLVM version of `ar` does not appear to have this bug.
Since this is only a problem that is more likely to occur on debug
builds and workarounds like enabling LTO can alleviate the problem, do
not recommend that the `llvm` package be added as part of the standard
package dependency set, but merely note that using `llvm-ar` can work
around the problem. Indeed, future OpenBSD versions may include updated
binutils which may have this bug fixed.
While we are here, the new concurrency features require libdispatch, and
since some of the necessary patches to libdispatch have not yet been
reviewed or accepted upstream yet to make it work on OpenBSD, recommend
that prospective builders for this platform still disable features that
depend on libdispatch for now.
Additionally, update the platform version number which has been tested.
It was originally designed for faster trasmission of syntax trees from
C++ to SwiftSyntax, but superceded by the CLibParseActions. There's no
deserializer for it anymore, so let's just remove it.
- `Mangle::ASTMangler::mangleAutoDiffDerivativeFunction()` and `Mangle::ASTMangler::mangleAutoDiffLinearMap()` accept original function declarations and return a mangled name for a derivative function or linear map. This is called during SILGen and TBDGen.
- `Mangle::DifferentiationMangler` handles differentiation function mangling in the differentiation transform. This part is necessary because we need to perform demangling on the original function and remangle it as part of a differentiation function mangling tree in order to get the correct substitutions in the mangled derivative generic signature.
A mangled differentiation function name includes:
- The original function.
- The differentiation function kind.
- The parameter indices for differentiation.
- The result indices for differentiation.
- The derivative generic signature.
CMake: fix build for Apple Silicon hosts
When building with `build-script` using these arguments
```
utils/build-script --skip-build-benchmarks
--skip-ios --skip-watchos --skip-tvos
--swift-darwin-supported-archs "arm64"
--sccache --release-debuginfo --test
```
the build fails with
```
ninja: error: 'stdlib/swift-test-stdlib-macosx-x86_64',
needed by 'stdlib/CMakeFiles/swift-test-stdlib', missing and no known rule to make it
```
I think that the "Getting Started" guide should avoid hardcoding `x86_64` arguments, and suggest using `$(uname -m)` instead. `SWIFT_PRIMARY_VARIANT_ARCH_default` could also get its value from `CMAKE_HOST_SYSTEM_PROCESSOR` in the root `CMakeLists.txt`.
Resolves SR-13943.
The main implication being that we allow for values to be leaked along dead end
blocks.
NOTE: For those who are unaware, a dead end block in SIL is a block that is
post-dominated in the same function by program terminating blocks (which we
model using unreachables).
