Given this
```
@objc protocol P { func f() }
class C: P { func f() {} }
```
the casts `C.self is any P` and `C.self as? any P` should always fail,
because the metatype of `C.self` does not have an `f()` implementation.
These casts previously succeeded because the runtime implementation
deferred to Obj-C's `[o conformsToProtocol:p]`, and that behaves
differently depending on whether `o` is a class instance or
a Class itself.
Since these casts should never succeed, I've just modified the
Swift runtime logic to fail whenever the source of the cast
is an Obj-C Class and the target is a protocol existential.
Resolves: rdar://106973771
Experiment shows that the vast majority (~99.99%) of keys with equal hashes have equal bytes. Fast-path that case by doing a memcmp before doing the deeper comparison.
rdar://110478978
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.
