On Windows, std::max_align_t is only 8-byte aligned, but Swift assumes 16-byte alignment. MaximumAlignment is our notion of the maximum alignment of a type, so use that instead.
Mangling can fail, usually because the Node structure has been built
incorrectly or because something isn't supported with the old remangler.
We shouldn't just terminate the program when that happens, particularly
if it happens because someone has passed bad data to the demangler.
rdar://79725187
Take the existing CompatibilityOverride mechanism and generalize it so it can be used in both the runtime and Concurrency libraries. The mechanism is preprocessor-heavy, so this requires some tricks. Use the SWIFT_TARGET_LIBRARY_NAME define to distinguish the libraries, and use a different .def file and mach-o section name accordingly.
We want the global/main executor functions to be a little more flexible. Instead of using the override mechanism, we expose function pointers that can be set by the compatibility library, or by any other code that wants to use a custom implementation.
rdar://73726764
* Dynamic Cast Rework: Runtime
This is a completely refactored version of the core swift_dynamicCast
runtime method.
This fixes a number of bugs, especially in the handling of multiply-wrapped
types such as Optional within Any. The result should be much closer to the
behavior specified by `docs/DynamicCasting.md`.
Most of the type-specific logic is simply copied over from the
earlier implementation, but the overall structure has been changed
to be uniformly recursive. In particular, this provides uniform
handling of Optional, existentials, Any and other common "box"
types along all paths. The consistent structure should also be
easier to update in the future with new general types.
Benchmarking does not show any noticable performance implications.
**Temporarily**, the old implementation is still available. Setting the
environment variable `SWIFT_OLD_DYNAMIC_CAST_RUNTIME` before launching a program
will use the old runtime implementation. This is only to facilitate testing;
once the new implementation is stable, I expect to completely remove the old
implementation.
* SR-12486: `T.self is Any.Protocol` is broken
This turned out to be fallout from https://github.com/apple/swift/pull/27572
which was in turn motivated by our confusing metatype syntax when generic variables are bound to protocols.
In particular, the earlier PR was an attempt to make the expression
`x is T.Type` (where `T` is a generic type variable bound to a protocol `P`)
behave the same as
`x is P.Type` (where `P` is a protocol).
Unfortunately, the generic `T.Type` actually binds to `P.Protocol` in this case (not `P.Type`), so the original motivation was flawed, and as it happens, `x is T.Type` already behaved the same as `x is P.Protocol` in this situation.
This PR reverts that earlier change and beefs up some of the tests around these behaviors.
Resolves SR-12486
Resolves rdar://62201613
Reverts PR#27572
Rather than using the forward declaration for the LLVMSupport types,
expect to be able to use the full declaration. Because these are
references in the implementation, there is no reason to use a forward
declaration as the full types need to be declared for use. The LLVM
headers will provide the declaration and definition for the types. This
is motivated by the desire to ensure that the LLVMSupport symbols are
properly namespaced to avoid ODR violations in the runtime.
This reduces the dependency on `LLVMSupport`. This is the first step
towards helping move towards a local fork of the LLVM ADT to ensure that
static linking of the Swift runtime and core library does not result in
ODR violations.
This seems to be the single most common bridge cast,
and repeated lookup seems to be a performance issue
for the common operation of bridging a string-valued
NSDictionary into Swift. Spending a couple of static
words of memory to memoize it should be a nice perf win.
Resolves rdar://55237013
* SR-12161 Casting P.self to P.Type regressed in iOS13.4 beta
An earlier fix for certain protocol casts inadvertently disabled
the check for a protocol being cast to its own metatype.
This rearranges the code so that identical types always succeed.
It also updates swift_dynamicCastMetatypeUnconditional to
include recent changes to swift_dynamicCastMetatype.
Note: These fixes only apply to debug/non-optimized builds.
Cast optimizations still break a lot of these cases.
SR-3871: Dynamic casting of existentials stored in Obj-C references
Arbitrary Swift objects get packaged into __SwiftValue containers so
that pointers to them can be passed into Obj-C. (Obviously, Obj-C
code can't do anything particularly useful with such pointers other
than refcount them and give them back to Swift code.) Those values come
back into Swift as either `Any` (existential box) or `AnyObject`
(anonymous object pointer) values. Dynamically casting those requires
first inspecting the outer value to get access to the actual type and
value in the __SwiftValue container.
The tryDynamicCastBoxedSwiftValue() function that handles this
was missing a check for the `Any` case, which is why directly
casting from `Any` would routinely fail.
Resolves SR-3871
Rather than attempting Error bridging early when trying to dynamically
cast to NSError or NSObject, treat it as the *last* thing we do when
all else fails. Push most of this code over into Objective-C-specific
handling rather than #ifdef'd into the main casting logic to make that
slightly more clear.
One oddity of Error/NSError bridging is that a class that conforms to
Error can be dynamically cast to NSObject via Error bridging. This has
always been known to the static compiler, but the runtime itself was
not always handling such a cast uniformly. Do so now,
uniformly. However, this forced us to weaken an assertion, because
casting a class type to NSError or NSObject can produce an object with
a different identity.
Fixes rdar://problem/57393991.
* SR-7732: Dynamic casting CFError to Error results in a memory leak
The special handling for casting CFError/NSError to Swift Error
type was using cleanup code that didn't correctly handle this case.
This replaces the cleanup code with a more targeted version.
Fixes: SR-7732
Fixes: rdar://problem/40423061
* Whitespace fixes
* Don't rely on localizable strings to verify test behavior.
I've verified this simplified test still leaks with
the original code and does not leak with the fixed code.
* Don't test against old runtimes that predate this fix
* Explicitly test both NSError and CFError
This is cleaner and it fixes a bunch of cases the old code didn't handle: @objc protocols, class bounds, and superclass constraints.
rdar://problem/56044443
This fixes cases like `type is T.Type` when T is generic specialized to a protocol type.
Note: the compiler can still optimize these checks away and will optimize this check down to `false` in some cases. We'll want to fix that as well.
rdar://problem/56044443
This makes for a cleaner and less implicit-context-heavy API, and makes it easier for symbolic
reference resolvers to do context-dependent things (like map the in-memory base address back to a
remote address in MetadataReader).
The swift side signature for `swift_swiftValueConformsTo` is:
`func swift_swiftValueConformsTo<T>(_: T.self) -> Bool`
This translates to:
`bool swift_swiftValueConformsTo(const Metadata *, const Metadata *)`
The elided parameter would be passed invalid values.. Running this on
Windows with optimizations triggered an optimization where the parameter
happened to be null as `rdx` is the second parameter rather than the 4th
parameter.
This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
Currently ignored, but this will allow future compilers to pass down source location information for cast
failure runtime errors without backward deployment constraints.
_dynamicCastToAnyHashable assumed that _swift_convertToAnyHashableIndirect takes its argument at +1, but that is no longer the case.
rdar://problem/44686587
When checking conformance requirements against an @objc protocol, also
check for an @objc existential using protocol_conformsToProtocol().
Fixes rdar://problem/45685649.
When searching the superclasses at runtime, e.g., to find a suitable
protocol conformance record, also consider the superclasses of CF
types, which were recorded in the metadata but otherwise unused.
Have clients pass the requirement base descriptor to
swift_getAssociatedTypeWitness(), so that the witness index is just one
subtraction away, avoiding several dependent loads (witness table ->
conformance descriptor -> protocol descriptor -> requirement offset)
in the hot path.
