The `ABI` headers had accidentally grown an `#include` into compiler headers,
allowing the enum constant values of the `ValueOwnership` enum to leak into
the runtime ABI. Sever this inappropriate relationship by declaring a separate
`ParameterOwnership` enum with ABI-stable values in the ABI headers, and
explicitly converting between the AST and ABI representation where needed.
Fixes rdar://122435628.
This includes runtime support for instantiating transferring param/result in
function types. This is especially important since that is how we instantiate
function types like: typealias Fn = (transferring X) -> ().
rdar://123118061
Add a distinct hook for `swift_willThrowTypedImpl()`.
This PR adds a hook for `swift_willThrowTypedImpl()` that is distinct from
`swift_willThrow()`. The current implementation of `swift_willThrowTypedImpl()` creates a
temporary existential box for the thrown error and calls the `_swift_willThrow` hook that
is set by XCTest and swift-testing. Unfortunately, this temporary existential box isn't
very useful because its address is not expected to be stable.
Instead, expose a separate hook, `_swift_willThrowTypedImpl`, whose signature matches
that of the new ABI function. This hook can then be used by XCTest and swift-testing to
distinguish between typed throws and untyped throws and avoids creating a temporary
existential box when it won't be useful.
As implemented, if `_swift_willThrowTypedImpl` is not set but `_swift_willThrow` is, the
`swift_willThrowTypedImpl()` will fall back to calling `_swift_willThrow` with a temporary
existential box. We might decide this is unnecessary, but I figured it would allow us more
time to stage adoption of the new hook in the testing libraries.
Resolves rdar://122824443.
We shouldn't call `__cxa_begin_catch` if built with `-fno-exceptions`,
because it's possible that the environment we're in won't include
the `__cxa_begin_catch` routine.
rdar://122995672
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.
Use exports, not symbols, when emitting a pointer target. Exports are what the linker can actually work with.
When searching for a nearby export to use for a pointer target, accept anything within the same segment, not just the same section. Only segments can be rearranged relative to each other, not sections within a segment, so this is safe and allows for more possible targets.
Disallow pointer targets with no export within the same segment. We attempted to emit a target that's relative to the section starting point in this case, but that didn't work. We'll revisit if it looks useful to do so.
In order to make this work, we resolve the export when writing a pointer instead of when emitting JSON, and make the writePointer functions failable. If writePointer fails, we'll fail to build the metadata and skip it.
Correctly handle the case where the names JSON contains a metadata we already constructed as part of a prior name. Previously we'd emit it twice, now it checks to see if it's already been built and do nothing in that case. Also save errors when a metadata can't be built, so subsequent attempts to build it can fail immediately.
When emitting fixups with ptrauth attributes, use the correct target kind "arm64_auth_ptr".
Fix the VerifyExternalMetadata.swift test not to load an arm64e runtime slice when testing arm64. That's normally fine, but we depend on loading the exact same dylib that we built prespecializations for.
rdar://122968337
This adds in hooks so that the new hash/isEqual interop
(which bridges Obj-C hash/isEqual: calls to the corresponding
Swift Hashable/Equatable conformances) can be selectively
disabled based on the OS and/or client.
For now, enable the new semantics everywhere except Apple platforms
(which have legacy apps that may be relying on the old semantics).
Instead of reading from `/proc/self/cmdline`, take advantage of the fact
that the initial stack layout is ABI specified, and that we already have
a pointer into it (`environ`). This lets us walk up the stack until we
find `argc`, at which point we also know where `argv` is.
We do this from a static initializer because a `setenv()` or `putenv()`
can change `environ` (if you add a new environment variable), and it's
even permissible to just outright change `environ` yourself too. It
seems reasonable to suggest to people that they shouldn't be doing
those things from a static initializer, and as long as they don't,
they won't run before we've had a chance to find `argv`.
Just in case someone _does_ do this, we also check that `environ`
points into the stack. If it doesn't, they won't get any arguments,
so if that happens, that's a clue that they're messing with `environ`
too early.
This works around a problem (#69658) with Docker Desktop 4.25.0 and
Rosetta, wherein we end up with an extra argument visible in
`/proc/self/cmdline`, and also avoids allocating memory for the
command line arguments.
rdar://117963394
The name of the `TaskExecutor` protocol was recently changed to remove
underscores after the feature was accepted in Swift Evolution. An implication
of that rename is that the `buildOrdinaryTaskExecutorRef` builtin changed
the type that it expected as the argument. However, the original change
landed in the standard library which as since produced swiftinterfaces
that contain the following inlinable code:
```
@inlinable public init<E>(ordinary executor: __shared E) where E : _Concurrency._TaskExecutor {
#if $BuiltinBuildTaskExecutor
self.executor = Builtin.buildOrdinaryTaskExecutorRef(executor)
#else
fatalError("Swift compiler is incompatible with this SDK version")
#endif
}
```
When a compiler containing the protocol rename attempts to type check the
above inlinable code, it crashes because the builtin is expecting an argument
conforming to `TaskExecutor`, which doesn't exist in this version of the
standard library. The issue is that the current compiler still supports
the `$BuiltinBuildTaskExecutor` feature guard, but the builtin supported
has since changed.
To resolve this issue, we need to stop supporting the `$BuiltinBuildTaskExecutor`
feature guard and introduce a new one that is only supported by compiler versions
that contain the rename. This approach relies on nothing having adopted the
API, otherwise we would need to stage in the rename as a parallel set of APIs,
and only remove the old APIs once nothing is relying on the old _Concurrency
swiftinterfaces.
Add cross-compilation flags for the newly added Swift source in `lib/ASTGen/`,
similar to how `SwiftCompilerSources/` is already cross-compiled for other
platforms. Make sure the Swift source in the compiler builds and links against
`SWIFTLIB_DIR` in this cross-compilation build directory, not the one that comes
with the native host compiler.
This requires changing the dependency chain in `CROSSCOMPILE` mode, as normally
the Swift compiler is built first when building natively for the host, then it's
used to build the stdlib. However, when cross-compiling the toolchain, the stdlib
must be cross-compiled first by the host compiler, then the portions of the
Swift compiler written in Swift must be cross-compiled with that new stdlib. All
these dependency changes simply change that compilation order when cross-compiling,
including removing the dependency that the Swift compiler is built before the
stdlib when cross-compiling the Swift compiler.
All changes in this pull are gated on the `CROSSCOMPILE` mode, so they will
not affect any of the existing CI or build presets.
