The standard library's swiftinterface must temporarily remain buildable when
`$TypedThrows` evaluates to false since there are still supported Swift 5.11
compilers that did not have the feature enabled by default. Declarations using
typed throws in their signatures are guarded in printed swiftinterface files
with `#if $TypedThrows` and therefore `@inlinable` code that uses those
declarations must also be conditionalized on `$TypedThrows`.
Introduces the first use of `@_DebugDescription` in the standard library, applying it
to `ObjectIdentifier`. In order to use the DebugDescription macro in the stdlib, the
following changes are required:
1. Compilation must reference the just built macros (ie `libSwiftMacros.dylib`), not
those from the SDK. This is addressed by adding an explicit `-external-plugin-path`
flag that overrides the defaults generated by the compiler (which uses SDK paths, where
the macro may or may not exist, and may not be the current version).
2. As DebugDescription uses `@_section`, compilation enables the `SymbolLinkageMarkers`
feature.
Note that the use of DebugDescription is conditionally enabled for the following
reasons:
1. Use is disabled in freestanding builds, where the stdlib macros are not built.
2. Use is temporarily disabled in Linux builds due to a dynamic loader issue that needs
further investigation
The dynamic loader error causing issues with Linux CI is:
> swift-plugin-server: error while loading shared libraries: libswiftGlibc.so: cannot
open shared object file: No such file or directory
This PR depended on #71639, #71588, and #71685.
I was looking through Swift's issues tab and found this issue (#57496), which points out the poor performance of `FlattenSequence/count`. The current `count` implementation calls `distance(from:to:)`, which iterates through the entire collection, so I thought I'd improve that method. The new version computes the distance as the sum of three parts, with a fast path when both indices belong to the same underlying collection. Note that it does this by calling either `count` or `distance(from:to:)` on each underlying collection, which makes `[repeatElement(0, count: Int.max)].joined().count` instant, for example.
`swift_willThrow` is called with an error right before it is thrown.
This existing entrypoint requires an already-boxed error existential;
with typed errors, we don't have the error existential on hand, so we
would need to allocate the box to throw a typed error. That's not okay.
Introduce a new `swift_willThrowTypedImpl` entry point into the runtime
that will first check for the presence of an error handler and, if one
is present, box the error to provide to the error handler. This
maintains the no-allocations path for typed errors while still
allowing existing error handlers to work.
This new entrypoint isn't available on older Swift runtimes, so create
a back-deployable shim called by the compiler. On new-enough platforms,
this will call through to `swift_willThrowTypedImpl`. On older
platforms, we drop the error and don't call the registered will-throw
handler at all. This is a compromise that avoids boxing when throwing
typed errors, at the cost of a slightly different experience for this
new feature on older runtimes.
Fixes rdar://119828459.
When the Swift module is not available, we'll synthesize the
Copyable/Escapable decls into the Builtin module.
In the future, it might be nice to just do this always, and define
typealiases for those types in the stdlib to refer to the ones in the
builtin module.
These functions were the odd ones out in not using `encoding` for this parameter label. Harmonizing this term will also make the documentation more consistent.
