* 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.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
Previously we had two separate mechanisms to turn a metatype
into a string. The swift_typeName() function was used to print
the metatype in a human-readable fashion, whereas the
_swift_buildDemanglingForMetadata() was used when naming
generated generic Objective-C classes.
Unify them, since what swift_typeName() does is redundant;
instead of going directly from the metatype to a human-readable
string, we can get the mangling, and print that using the
demangler.
This fixes some issues with unnecessary parenthesis when
printing function types, and also allows Objective-C classes
to be instantiated with nested generic types as parameters.
This allows dynamic casting to succeed between tuple types with
different element types, converting each element in turn. Fixes
rdar://problem/19892202.
When printing a tuple via print(...), print tuple labels when they are
available. This is possible now that the runtime metadata properly
stores tuple labels. Fixes rdar://problem/23130016.
Introduce narrow support for tuple/tuple dynamic casts that merely add
or remove labels, but require the element types to match exactly. This
gets us back to allowing the same correct dynamic casts as in Swift
3.0, when labels were completely ignored.