Emitting a signpost for the first time can trigger lazy setup of the logging system, and doing this in the wrong context can cause deadlocks. Check to see if the logging system is already set up, and only emit signposts if it has been to avoid triggering this.
As it's hard to determine if the "is it set up?" function is available in the SDK we're building against, only do this in OS builds, as it's not particularly useful in local builds.
rdar://124620772
PR #71620 made this behavior conditional as a way to help
provide binary compatibility for legacy software that might
be relying on the old behavior.
So far, it appears the only such problems arose from the
SwiftObject behavior changes, not from SwiftValue behavior.
So let's optimistically back this out and make the new behavior
unconditional.
Resolves rdar://127839540
The standard library defines
```
protocol BitwiseCopyable {}
typealias _BitwiseCopyable = BitwiseCopyable
```
For current compilers, `BitwiseCopyable` is a "known protocol".
For older compilers, it is not; instead `_BitwiseCopyable` is. So
print the following into the swiftinterface for those older compilers:
```
protocol _BitwiseCopyable {}
typealias BitwiseCopyable = _BitwiseCopyable
```
rdar://127755503
This adds a `getSpareBits` method to all the TypeInfo classes
that returns a suitable bitmask indicating the spare bits available
in values of this type. This gives us a way to recursively explore
the type tree and build up a full spare bit mask for an arbitrary type.
Happily, it appears we actually do have enough information to do this
calculation entirely from first principles, without requiring additional
reflection information. So once this is stable, we should remove my
earlier incomplete effort to publish spare bit mask info in the reflection
data, as that adds unnecessary metadata to every binary.
This doubtless still has plenty of holes, but seems sufficient
to handle a few basic enum types, including the stdlib DecodingError
which was used as an example to work out some key issues.
Added the _modules workaround to make the compiler pull in the correct
module when someone does `import stdc_assert` (for instance).
Fix various niggles.
rdar://123503615
We need to declare separate top-level modules for every header in
the musl C library. Note that our set-up here does require some
tweaks to musl itself (specifically, the `alltypes.h` header needs
some fairly serious massaging to make it module compatible; in
particular, we need to pull out every type declaration into its
own separate modularized header in `bits/types`).
Also update `Platform.swift` a little for more musl support.
rdar://123503615
Mostly this just means adding `Musl` as a module dependency of various
things and making sure that we build things for `swift_static` even
if `SWIFT_BUILD_STATIC_STDLIB` isn't enabled.
There's also a slight difference in the declaration of `memcmp()`;
musl's declaration is more like the one we have on Darwin.
rdar://123508245
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
