Use the new `SWIFT_SDK_<sdk>_STATIC_LINKING_SUPPORTED` and
`_STATIC_ONLY` flags instead of hardcoding support for Linux
and WASI.
Also, use the `_LIB_SUBDIR` variable rather than lowercasing
the SDK.
rdar://123504757
When SWIFT_BUILD_STATIC_STDLIB=ON, SWIFT_BUILD_DYNAMIC_STDLIB=OFF, and
the sdk being built is not a static-only (e.g. WASI), the build fails
due to duplicate custom command rules against the same output path.
In the case of WASI, the static archive should be copied into lib/swift
by the first lipo target, and then the second lipo target should copy it
into lib/swift_static.
```
CMake Error at cmake/modules/SwiftAddCustomCommandTarget.cmake:144 (add_custom_command):
Attempt to add a custom rule to output
/home/build-user/build/buildbot_linux/wasmstdlib-linux-x86_64/lib/swift_static/wasi/libswiftCore.a.rule
which already has a custom rule.
Call Stack (most recent call first):
stdlib/cmake/modules/AddSwiftStdlib.cmake:673 (add_custom_command_target)
stdlib/cmake/modules/AddSwiftStdlib.cmake:2657 (_add_swift_lipo_target)
stdlib/public/core/CMakeLists.txt:401 (add_swift_target_library)
```
* Avoid using generic static members on Duration across module boundaries
Because the clocks are implemented in Concurrency, but Duration is in the Swift module, these don't get specialized. Add a fully-concrete internal init in Concurrency to avoid the problem.
* Call self.init(_high:low:) explicitly.
* Add availability annotation.
This means that they can't use _Int128 for their implementation, but efficient implementation of these using only 64b arithmetic is pretty straightforward, so that's OK. This allows them to be specialized and mostly optimized away in release builds.
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
rdar://127379960
When the spare bits of an Error objects are used to store tag bits, this caused the enum tag to be lost, which caused the wrong enum cases to be matched.
With the introduction of `next(isolation:)` into the task group types,
we removed the public APIs for the no-argument `next()` versions,
leaving them only as `@usableFromInline internal` entrypoints for the
ABI. Because the `next(isolation:)` versions have a default argument,
this was sufficient for providing source compatibility for calls, but
not for protocol conformances.
Bring these APIs back publicly. Fixes rdar://127499568.
Fix some indentation issues.
Change `build-script-impl` to make `build-linux-static` a positive argument.
Fix documentation for `--linux-archs` and `--linux-static-archs` (the options
are comma separated for `build-script`, but semicolon separated for
`build-script-impl`).
Set the default for `linux-static-archs` to `x86_64, aarch64` so that we
install the expected content in the toolchain.
Add missing default for `test_linux_static`.
Make sure to pass down `--skip-build-linux` and `--build-linux-static`.
Factor out config file generation and call it from the install step in `llvm.py`
as well as from the build step.
rdar://123503470
I accidentally copy and pasted the mangled symbol names in the wrong order, so existing callers got directed to the wrong entry points, and things got terribly, terribly wrong.
(We badly need a sensible replacement for these `@_silgen_name` hacks.)
Huge thanks to @edymtt for spotting this!
rdar://127016847
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
Instead of appending characters one-by-one, which resizes the resulting string multiple times, let's reserve the required number of bytes beforehand.
rdar://127423949
Merge the three-stage operation originally designed for field vectors into a single unified loop that acts directly on the ivar offsets instead of using a faux field offset vector.
We really don’t need ‘em; we can just adjust the direct field offsets.
The runtime entry point currently uses a weird little hack that we will refactor away shortly.
When an @objc @implementation class requires the use of `ClassMetadataStrategy::Update` because some of its stored properties do not have fixed sizes, we adjust the direct field offsets during class realization by emitting a custom metadata update function which calls a new entry point in the Swift runtime. That entry point adjusts field offsets like `swift_updateClassMetadata2()`, but it only assumes that the class has Objective-C metadata, not Swift metadata.
This commit introduces an alternative mechanism which does the same thing without using any Swift-only metadata. It’s a rough implementation with important limitations:
• We’re currently using the field offset vector, which means that field offsets are being emitted into @objc @implementation classes; these will be removed.
• The new Swift runtime entry point duplicates a lot of `swift_updateClassMetadata2()`’s implementation; it will be refactored into something much smaller and more compact.
• Availability bounds for this feature have not yet been implemented.
Future commits in this PR will correct these issues.
as warnings.
Marking the closure parameter to these inits as `@Sendable` changed the
inferred isolation of closure arguments in actor-isolated contexts, which
caused new effects checker errors when accessing isolated properties and
methods without `await`. Mark these `init`s as `@preconcurrency`, and fix
the effects checker to downgrade those errors to warnings when the context
of the call is `@preconcurrency`.
There were two categories of problem for older compilers that consume the
stdlib `.swiftinterface`:
- The `case .some(borrowing x)` syntax isn't accepted; use `_borrowing`
- Various functions that addopted `~Copyable` generic constraints conflict with
the `@usableFromInline` ABI stubs that were left in to preserve compatibility
when the functions are printed with `~Copyable` constraints stripped. The stubs
need to have different names to get out of the way.
Resolves rdar://127132742
We attempted to use the declaration if it exists, and fall back to dlsym. This didn't actually work and we always call dlsym. Include the right header (when available) and add a weak check to the direct call.
rdar://127116080
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
Even with `std::hex`, the `uint8_t` values are being printed as characters, not hex
values. This change casts the value to `int`, which results in the hex representation
being properly printed.
