When ObjC interop is enabled, we emit what we think will be the class's InstanceStart and InstanceSize based on what we know about the superclass. We then fix up those values at runtime if they don't match. The compiler will emit this data into read-only memory if it knows they will always match, and then the runtime avoids writing to these fields if they already contain the correct value.
However, the compiler aligns the InstanceStart, but instance size is not aligned. For example:
class Super<T> { var bool = true }
class Sub: Super<Int> { var obj: AnyObject? }
Super's InstanceSize is 17 (on 64-bit) but Sub's InstanceStart is 24. The compiler sees a fixed layout and emits Sub's rodata into constant memory. The runtime sees that 24 does not equal 17 and tries to update it, but we don't want it to.
Instead, only update InstanceStart if it's too small to accommodate the superclass's InstanceSize. If it's overlay large then we'll just leave it alone. The compiler underestimates InstanceStart when it doesn't know the superclass's size so this should only happen due to alignment.
rdar://123695998
Github PR #71620 mixed up one of the bincompat conditionals.
It also had some errors in the tests for ObjC interop.
For now, this leaves the legacy behavior in place for
all Apple platforms.
Have SWIFT_DEBUG_LIB_PRESPECIALIZED_PATH use dlopen with RTLD_NOLOAD. We don't want it to allow loading arbitrary dylibs. Instead, a user can use something like DYLD_INSERT_LIBRARIES to load the dylib, which we will then pick up in the runtime, and processes that deny DYLD_INSERT_LIBRARIES will not be able to work around it with SWIFT_DEBUG_LIB_PRESPECIALIZED_PATH.
rdar://123643585
This change enables the `--gc-sections` linker flag for WebAssembly
targets by default. This flag has been disabled because it did not
respect `llvm.used` and it caused stripping `swift5` metadata sections
even though they were used through encapsulation symbols (a.k.a `__start`/`__stop`).
The issue has been fixed in the LLVM side (ba3c1f9ce3)
by adding new segment flags to the WebAssembly object file format.
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
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).
Rather than just on or off, I've changed it to allow "off", "fast",
or "full". "fast" means that we'll do symbol lookup, but we won't
try to find inline frames and we won't run line number programs
(those are the things that are taking considerable time in some
cases).
rdar://122302117
The other new runtime functions appear to have a leading underscore.
It makes sense in this case because we don't expect anything to call
this directly (other than the unwinder).
rdar://120952971
The previous approach was effectively to catch the exception and then
run a trap instruction. That has the unfortunate feature that we end
up with a crash at the catch site, not at the throw site, which leaves
us with very little information about which exception was thrown or
where from.
(Strictly we do have the exception pointer and could obtain exception
information, but it still won't tell us what threw it.)
Instead of that, set a personality function for Swift functions that
call potentially throwing code, and have that personality function
trap the exception during phase 1 (i.e. *before* the original stack
has been unwound).
rdar://120952971
`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.
Symbolication can take some time, depending on the binaries involved.
In certain contexts it's better for the backtrace to finish quickly,
and then symbolication could be done offline.
rdar://122302117
rdar://117083470
An existential can contain a different type than the one that is being assigned, so we have to check the types and handle the values accordingly.
We run the builder, then use a small program that converts the JSON output into C code that generates the data. Compile that into a bundle, then load it as the prespecializations library. Then scan all the entries in the table and compare them with what the runtime builds dynamically.
We were doing a linear scan of the table contents as a stopgap. Stop doing that, and compute the proper key for the lookup, matching the one used in the builder.
Not quite NFC because apparently the representation bleeds into what's
accepted in some situations where we're supposed to be warning about
conflicts and then making an arbitrary choice. But what we're doing
is nonsense, so we definitely need to break behavior here.
This is setting up for isolated(any) and isolated(caller). I tried
to keep that out of the patch as much as possible, though.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
ASL is deprecated in macOS 10.12. It may be time to transition to os_log now
that deployment targets have been raised to 10.12, but until that project
starts these warnings are just pollution.
Filed rdar://121066531 to track adoption of `os_log()` if appropriate.
