Using symbolic references instead of a text based mangling avoids the
expensive type descriptor scan when objective c protocols are requested.
rdar://111536582
The following sequence of casts would previously succeed
```
struct S {}
let s = S() as AnyObject
s as? NSObject
```
The final cast here should fail, since `S` clearly is not a
subclass of NSObject. But it would previously succeed because
the `as AnyObject` would package the struct into an ObjC-compatible
`__SwiftValue` class. This latter is an NSObject subclass.
This bug was fixed in the main `swift_dynamicCast` runtime function
some time ago, but not in the `swift_dynamicCastObjCClass` which
is chosen by IRGen to optimize casts to ObjC class types.
This PR changes the latter to test for `__SwiftValue` and fall
back to the former in that case in order to get the correct
handling. Falling back to `swift_dynamicCast` also ensures that
the contents of the `__SwiftValue` are correctly unwrapped/bridged/etc
as necessary to fully support Swift casting semantics.
Resolves: rdar://111422725
TODO: I've left an XFAILed test here about the behavior of `type(of:)`
with `__SwiftValue` boxes.
In C++20, the compiler will synthesize a version of the operator
with its arguments reversed to ease commutativity. This reversed
version is ambiguous with the hand-written operator when the
argument is const but `this` isn't.
The `ivar` reference still pointed to the original list, so the first modification went to the wrong place. Change `ivar` to a pointer, and re-point it when we copy the list.
rdar://116339597
There's often nothing that needs to be fixed up in the ivar list. In that case, we can avoid copying it. This saves time and memory, and allows the class rodata to be in immutable memory.
rdar://116189946
When a Swift struct gets bridged to Obj-C, we box it into an opaque
`_SwiftValue` Obj-C object. This object previously supported the
Obj-C `isEqual:` and `hash` selectors by dispatching to the Swift
Hashable conformance, if present.
This does not work if the Swift struct conforms to Equatable but
does not conform to Hashable. This case seems to have been
overlooked in PR #4124.
This PR extends the earlier work to support `isEqual:` by
first checking for a Hashable conformance, then falling back
on an Equatable conformance if there is no Hashable conformance.
Resolves rdar://114294889
The more awkward setup with pushGenericParams()/popGenericParams()
is required so that when demangling requirements and field types
we get the correct pack-ness for each type parameter. The pack-ness
is encoded as part of the generic signature, and not as part of
the type parameter mangling itself.
Fixes the ASTDemangler issue from rdar://problem/115459973.
By using a specialize function, we only call through the witness table and fetch the layout string once for the whoe buffer, instead of once per element.
When we're statically linking the standard library, we need to force
the inclusion of the backtracing code in the runtime, otherwise we don't
get on-crash backtraces.
Also, add a test to make sure that this works.
rdar://115774613
Fix the issue that fatal errors in certain cases don't terminate the
process and the process keeps running in Windows by disabling the
exception swallowing that supressed the illegal instruction exceptions
coming from llvm.trap.
When the differentiating a function containing loops, we allocate a linear map context object on the heap. This context object may store non-trivial objects, such as closures, that need to be released explicitly. Fix the autodiff linear map context allocation builtins to correctly release such objects and not just free the memory they occupy.
We fix up the VWT pointer, but not the heap destroyer. This doesn't matter for classes which use ObjC refcounting, which is the common case for dynamic subclasses, because that doesn't use the heap destroyer pointer. But it does matter for classes that use native Swift refcounting, such as classes that don't inherit from NSObject, or actors.
rdar://113657917
