Emit and resolve idValue of KeyPath as an absolute pointer if relative
function pointer is turned-off on Wasm target.
The existing ABI can't distinguish an idValue between function pointer
or data pointer in use-site at compile-time and also at runtime. So this
patch adds a new id resolution scheme `ResolvedAbsolute` to distinguish
them at runtime properly.
When SWIFT_COMPACT_ABSOLUTE_FUNCTION_POINTER is enabled, relative direct
pointers whose pointees are functions will be turned into absolute
pointer at compile-time.
Starting with Android 11, AArch64 placed a tag in the top byte of pointers to
allocations, which has been slowly rolling out to more devices and collides
with Swift's tags. Moving these tags to the second byte works around this
problem.
Because the attribute is part of the declaration, putting a doc comment
between the attribute and "public" ends up with the comment in the
middle of the declaration. This results in SourceKit skipping over the
comment, and the docs not being shown.
Fixes <rdar://problem/58716408>.
Call through to _swift_modifyAtReferenceWritableKeyPath_impl in that case. This fixes an assertion failure (or worse) when upcasting a ReferenceWritableKeyPath and then using subscript(keyPath:) to modify a value with it.
rdar://74191390
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
While the existing _forEachField in ReflectionMirror.swift
already gives the offsets and types for each field, this isn't
enough information to construct a keypath for that field in
order to modify it.
For reference, this should be sufficent to implement the features
described here: (https://forums.swift.org/t/storedpropertyiterable/19218/62)
purely at runtime without any derived conformances for many types.
Note: Since there isn't enough reflection information for
`.mutatingGetSet` fields, this means that we're not able to support
reflecting certain types of fields (functions, nonfinal class fields,
etc). Whether this is an error or not is controlled by the `.ignoreUnknown`
option.
Call through to swift_setAtReferenceWritableKeyPath in that case. This fixes an assertion failure (or worse) when upcasting a ReferenceWritableKeyPath and then using subscript(keyPath:) to write a value with it.
rdar://problem/70609888
This adds a mostly flow-insensitive analysis that runs before the
dominator-based transformations. The analysis is simple and efficient
because it only needs to track data flow of currently in-scope
accesses. The original dominator tree walk remains simple, but it now
checks the flow insensitive analysis information to determine general
correctness. This is now correct in the presence of all kinds of nested
static and dynamic nested accesses, call sites, coroutines, etc.
This is a better compromise than:
(a) disabling the pass and taking a major performance loss.
(b) converting the pass itself to full-fledged data flow driven
optimization, which would be more optimal because it could remove
accesses when nesting is involved, but would be much more expensive
and complicated, and there's no indication that it's useful.
The new approach is also simpler than adding more complexity to
independently handle to each of many issues:
- Nested reads followed by a modify without a false conflict.
- Reads nested within a function call without a false conflict.
- Conflicts nested within a function call without dropping enforcement.
- Accesses within a generalized accessor.
- Conservative treatment of invalid storage locations.
- Conservative treatment of unknown apply callee.
- General analysis invalidation.
Some of these issues also needed to be considered in the
LoopDominatingAccess sub-pass. Rather than fix that sub-pass, I just
integrated it into the main pass. This is a simplification, is more
efficient, and also handles nested loops without creating more
redundant accesses. It is also generalized to:
- hoist non-uniquely identified accesses.
- Avoid unnecessarily promoting accesses inside the loop.
With this approach we can remove the scary warnings and caveats in the
comments.
While doing this I also took the opportunity to eliminate quadratic
behavior, make the domtree walk non-recursive, and eliminate cutoff
thresholds.
Note that simple nested dynamic reads to identical storage could very
easily be removed via separate logic, but it does not fit with the
dominator-based algorithm. For example, during the analysis phase, we
could simply mark the "fully nested" read scopes, then convert them to
[static] right after the analysis, removing them from the result
map. I didn't do this because I don't know if it happens in practice.
If a key path literal appears in a generic context with an existing context descriptor, this will allow us to
save some code size by not having to emit a separate GenericEnvironment descriptor.
Always use mangled type names to represent type metadata in keypath patterns.
For generic types, use the generic environment to pull substituted types
from the instantiation arguments.
Finishes the type metadata part of rdar://problem/38038799.
Extend the key-path pattern with a representation of the generic environment
of the key-path, which includes the generic parameters and generic
requirements of the environment.
Simplify the signature of the internal _getTypeByMangledName() used by the
standard library to what we actually (currently) use. Drop it as a
compatibility override, because it’s not a useful place to introduce
customization.
When we emit "false" symbolic references to accesors for conformances or
type metadata, ensure that we end up with two-byte-aligned symbolic
references. This addresses a problem with ARM+Thumb compilation where the
low bit wasn't getting set for Thumb code.
Fixes rdar://problem/46067353.
When a type in keypath metadata is non-dependent, use a mangled type name
rather than a symbolic reference to an accessor function.
Part of rdar://problem/38038799.
Switch key path metadata over to mangled names for each of the places it
refers to either a type metadata accessor or a witness table accessor. For
now, the mangled name is a symbolic reference to the existing accessors.
Part of rdar://problem/38038799.
Previously, the stdlib provided:
- getters for AnyKeyPath and PartialKeyPath, which have remained;
- a getter for KeyPath, which still exists alongside a new read
coroutine; and
- a pair of owned mutable addressors that provided modify-like behavior
for WritableKeyPath and ReferenceWritableKeyPath, which have been
replaced with modify coroutines and augmented with dedicated setters.
SILGen then uses the most efficient accessor available for the access
it's been asked to do: for example, if it's been asked to produce a
borrowed r-value, it uses the read accessor.
Providing a broad spectrum of accessor functions here seems acceptable
because the code-size hit is fixed-size: we don't need to generate
extra code per storage declaration to support more alternatives for
key paths.
Note that this is just the compiler ABI; the implementation is still
basically what it was. That means the implementation of the setters
and the read accessor is pretty far from optimal. But we can improve
the implementation later; we can't improve the ABI.
The coroutine accessors have to be implemented in C++ and used via
hand-rolled declarations in SILGen because it's not currently possible
to declare independent coroutine accessors in Swift.
Use relative references instead of pointers so that the pattern can be true-const. Instead of trying
to instantiate a constant key path literal in-place, point to a cache variable that we can store
a pointer to the shared instance into when instantiated. Now that the pattern format has diverged
significantly from the instance format, simplify and refactor the instantiation code using a walker
for the pattern format instead of trying to reuse the code for working with instantiated instances.
rdar://problem/42674576
General case:
—
begin_access A (may or may not have no_nested_conflict)
load/store
end_access
apply // may have a scoped access that conflicts with A
begin_access A [no_nested_conflict]
load/store
end_access A
—
The second access scope does not need to be emitted.
NOTE: KeyPath access must be identified at the top-level, non-inlinable stdlib entry point.
As such, The sodlib entry pointed is annotated by a new @_semantics that is equivalent to inline(never)
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
