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)
This fixes the "AST type changed, override is ABI compatible" case,
which enables the test cases previously marked with 'FIXME' in
vtable_thunks_reabstraction to pass.
Flesh out TypeConverter::requiresNewVTableEntry() and add tests
to (hopefully) exercise this support.
A few cases marked with FIXME still fail; looks like SILGenApply
is still not using the correct formal types for class method calls.
The output is rather verbose and repetitive but we want to
ensure it doesn't change unexpectedly as part of ABI stability,
and it provides a good test case for the demangler as well.
When this test was first added, concrete subclasses of generic
subclasses were not supported, but now they are, so remove some
useless generic parameters that add no value.
Type::subst() does stupid things if you give it a
GenericFunctionType, attempting to build a new "substituted"
GenericSignature by hand.
As the newly-added test case demonstrates, this can trigger
assertions, and the callers of adjustSuperclassMemberDeclType()
didn't care about the generic signature anyway, so strip it off
first.
Soon, I want to have Type::subst() assert if it encounters a
GenericFunctionType, and remove all the junk there altogether,
but there's more work to be done first.
Progress on <rdar://problem/30817732> (RxCocoa build failures on
master), but now it hits further regressions.
Also for class method callees, use the formal type of the base
method and not the override, fixing an issue with concrete
subclasses of generic base classes which bind a generic
parameter to a tuple type.
Fixes <https://bugs.swift.org/browse/SR-3541>.
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
When a derived class specializes its base class, e.g. 'class Derived: Base<Int>', the natural abstraction levels of its methods may differ from the original base class's more abstract methods. Handle this by using the reabstraction machinery to thunk values when necessary. Merge the existing optionality thunking support into the reabstraction code, where witness thunking and similar convention adjustments may also be able to use it, if we desire. Fixes rdar://problem/19760292.
Swift SVN r28505
