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.
Read a list of disabled process names from the prespecializations library, and turn the feature off if the current process matches. Also allow passing process names in environment variables. Processes can be disabled by name using SWIFT_DEBUG_LIB_PRESPECIALIZED_DISABLED_PROCESSES, and a disable can be overridden with SWIFT_DEBUG_LIB_PRESPECIALIZED_ENABLED_PROCESSES.
rdar://126216786
Call `swift_clearSensitive` after destroying or taking "sensitive" struct types.
Also, support calling C-functions with "sensitive" parameters or return values. In SIL, sensitive types are address-only and so are sensitive parameters/return values.
Though, (small) sensitive C-structs are passed directly to/from C-functions. We need re-abstract such parameter and return values for C-functions.
WebAssembly does not support _Float16 type, so we need to guard the use
of the type. Unfortunately, Clang does not provide a good way to detect
the support of _Float16 type at compile time, so just disable for wasm
targets.
We can easily test all 2**16 values, so let's do it. Also now _Float16 is properly supported in clang, so we can pass arguments to CPP that way, which lets us get snan right on more platforms.
This introduces a non-Darwin (non-CrashReporter) storage for error
messages to allow extraction for crash reporting. This is initially
meant to be used on Windows, though it is generic enough to be used on
any platform.
We need to check for overridden images on every image load, otherwise
XCTest (among others) may `dlopen()` an image that pulls in something
that is overridden, at which point the prespecialized metadata won't
match the image we loaded.
rdar://125727356
When we fail to look up a type by name, we print an error, then try to compare anyway, which crashes. Skip the comparison when that happens.
While we're in there, modify _swift_validatePrespecializedMetadata to be more useful for debugging, by removing the parameters and having it print the results directly.
Introduce metadata and runtime support for describing conformances to
"suppressible" protocols such as `Copyable`. The metadata changes occur
in several different places:
* Context descriptors gain a flag bit to indicate when the type itself has
suppressed one or more suppressible protocols (e.g., it is `~Copyable`).
When the bit is set, the context will have a trailing
`SuppressibleProtocolSet`, a 16-bit bitfield that records one bit for
each suppressed protocol. Types with no suppressed conformances will
leave the bit unset (so the metadata is unchanged), and older runtimes
don't look at the bit, so they will ignore the extra data.
* Generic context descriptors gain a flag bit to indicate when the type
has conditional conformances to suppressible protocols. When set,
there will be trailing metadata containing another
`SuppressibleProtocolSet` (a subset of the one in the main context
descriptor) indicating which suppressible protocols have conditional
conformances, followed by the actual lists of generic requirements
for each of the conditional conformances. Again, if there are no
conditional conformances to suppressible protocols, the bit won't be
set. Old runtimes ignore the bit and any trailing metadata.
* Generic requirements get a new "kind", which provides an ignored
protocol set (another `SuppressibleProtocolSet`) stating which
suppressible protocols should *not* be checked for the subject type
of the generic requirement. For example, this encodes a requirement
like `T: ~Copyable`. These generic requirements can occur anywhere
that there is a generic requirement list, e.g., conditional
conformances and extended existentials. Older runtimes handle unknown
generic requirement kinds by stating that the requirement isn't
satisfied.
Extend the runtime to perform checking of the suppressible
conformances on generic arguments as part of checking generic
requirements. This checking follows the defaults of the language, which
is that every generic argument must conform to each of the suppressible
protocols unless there is an explicit generic requirement that states
which suppressible protocols to ignore. Thus, a generic parameter list
`<T, Y where T: ~Escapable>` will check that `T` is `Copyable` but
not that it is `Escapable`, and check that `U` is both `Copyable` and
`Escapable`. To implement this, we collect the ignored protocol sets
from these suppressed requirements while processing the generic
requirements, then check all of the generic arguments against any
conformances not suppressed.
Answering the actual question "does `X` conform to `Copyable`?" (for
any suppressible protocol) looks at the context descriptor metadata to
answer the question, e.g.,
1. If there is no "suppressed protocol set", then the type conforms.
This covers types that haven't suppressed any conformances, including
all types that predate noncopyable generics.
2. If the suppressed protocol set doesn't contain `Copyable`, then the
type conforms.
3. If the type is generic and has a conditional conformance to
`Copyable`, evaluate the generic requirements for that conditional
conformance to answer whether it conforms.
The procedure above handles the bits of a `SuppressibleProtocolSet`
opaquely, with no mapping down to specific protocols. Therefore, the
same implementation will work even with future suppressible protocols,
including back deployment.
The end result of this is that we can dynamically evaluate conditional
conformances to protocols that depend on conformances to suppressible
protocols.
Implements rdar://123466649.
We can't use os_log functionality in logd, diagnosticd, or notifyd. Check for them and disable tracing in those processes.
Add a new TracingCommon.h for common code shared between swiftCore and swift_Concurrency tracing. Add a single function that checks if tracing should be enabled, which now checks if os_signpost_enabled is available, and if the process is one of these. Modify the tracing code to check this before creating os_log objects.
rdar://124226334
Don't use `#cmakedefine` to define values that can be zero.
`#cmakedefine` only sets the definition when the corresponding value in
CMake itself has a truthy value. `0` has a false-y value, so
SWIFT_VERSION_MINOR is undefined for 6.0 resulting in some things
breaking.
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).
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.
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.
Don't use strcmp to compare the candidate key with the search key, as the search key may not be NUL terminated. Use strncmp and a length check on the candidate key.
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.
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
Create a version of the metadata specialization code which is abstracted so that it can work in different contexts, such as building specialized metadata from dylibs on disk rather than from inside a running process.
The GenericMetadataBuilder class is templatized on a ReaderWriter. The ReaderWriter abstracts out everything that's different between in-process and external construction of this data. Instead of reading and writing pointers directly, the builder calls the ReaderWriter to resolve and write pointers. The ReaderWriter also handles symbol lookups and looking up other Swift types by name.
This is accompanied by a simple implementation of the ReaderWriter which works in-process. The abstracted calls to resolve and write pointers are implemented using standard pointer dereferencing.
A new SWIFT_DEBUG_VALIDATE_EXTERNAL_GENERIC_METADATA_BUILDER environment variable uses the in-process ReaderWriter to validate the builder by running it in parallel with the existing metadata builder code in the runtime. When enabled, the GenericMetadataBuilder is used to build a second copy of metadata built by the runtime, and the two are compared to ensure that they match. When this environment variable is not set, the new builder code is inactive.
The builder is incomplete, and this initial version only works on structs. Any unsupported type produces an error, and skips the validation.
rdar://116592420
which executor for which type of setting, is consolidated and we have a
single knob we use to determine when to use dispatch as our global
executor.
Radar-Id: rdar://problem/119416196
