Add all of the generic parameters from outer contexts as well. This only
occurs in ill-formed code, but maintains a GenericSignatureBuilder
invariant that it knows about all of the generic parameters in play.
Use the declaration-based name lookup facilities to re-implement
ProtocolDecl::getInheritedProtocols(), rather than dynamically selecting
between the requirement signature and the inherited types. This reduces
dependencies for this computation down to basic name lookup (no semantic
analysis) and gives us a stable result.
When looking for a representative superclass constraint, take into
account other same-type constraints by comparing against the resolved
superclass constraint type rather than the type as spelled.
Fixes SR-8179 / rdar://problem/41851224.
A constraint like `Parameter == SomethingConcrete` means references to
`Parameter` in that context behave like `SomethingConcrete`, including for name
resolution. Handling the parameter as just a parameter type means that it won't
find any non-protocol nested types (i.e. things other than associated types and
protocol typealiases are invisible).
Fixes rdar://problem/42136457 and SR-8240.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
This doesn't fix the fundamental problem of correctly handling such cases, but
it is better than the "error message" that occurred previously:
Assertion failed: ((bool)typeSig == (bool)extensionSig && "unexpected generic-ness mismatch on conformance").
Fixes the crash rdar://problem/41281406 (that in
https://bugs.swift.org/browse/SR-6569 (rdar://problem/36068136)),
https://bugs.swift.org/browse/SR-8019 (rdar://problem/41216423) and
https://bugs.swift.org/browse/SR-7989 (rdar://problem/41126254).
We need to make sure they don't end up as "concrete" equivalence
classes, because they behave more like unresolved ones.
Fixes rdar://problem/40009245.
Concrete and superclass constraints may be written involving type parameters
that are later resolved to concrete types. Perform the substitution to
ensure that type equality within constraint checking accounts for other
same-type constraints.
Fixes assertion in rdar://problem/40428709.
This claws back some of the regression of
2feb830b58 on certain generics heavy code.
rdar://problem/40005262 (no-opt) goes from 7.83 -> 5.75 and
rdar://problem/40010847 (opt) goes from 90.7 -> 66.6 (both -27%).
We could end up recursing through getTypeInContext() before we had time to
diagnose the recursion, so be *certain* that we can't recurse here to fix
a few crashes.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Generic typealiases can add requirements that aren't used by their
underlying type. For example, CountableRange in the standard library:
public typealias CountableRange<Bound: Comparable> = Range<Bound>
Perform requirement inference based on uses of generic typealiases,
such that a generic function like this:
func f<T>(_: CountableRange<T>) { }
will infer T: Bound from the use of CountableRange.
Note that this does not yet work for extensions.
Swift complains about redundant inheritance of a protocol, and
canonicalizes away such redundancies in its metadata. Clang does not
warn about such redundancies, nor does the Objective-C "conforms to
protocol" check take inheritance into account. Extend the existing
"redundant inheritance" hack (designed for JSExport) to cover all
protocols defined in Objective-C, so we match Clang's output of
Objective-C metadata.
Fixes SR-7130 / rdar://problem/38394637.
Eliminate some redundant work in the GenericSignatureBuilder by only merging
one nested type per name, rather than all nested types that have that same
name.
Same-type constraints are one of the primary places where potential
archetypes are used explicitly in the GenericSignatureBuilder. Switch
the representation over to a dependent type (represented by a `Type`)
instead, furthering the demise of PotentialArchetype.
Same-type constraints are (still) described in terms of potential
archetypes, so push the "realization" operation for potential
archetypes down into the function that adds a same-type constraint
between type parameters.
GenericSignatureBuilder::addSameTypeRewriteRule() was described in
terms of an equivalence class and a potential archetype. Rework it in
terms of two dependent types (i.e., the anchors of their equivalence
classes), so we don't need to rely on the PotentialArchetype
mechanism.
Make GenericSignatureBuilder::getCanonicalTypeParameter() independent of
equivalence classes. This is primarily cleanup, because all of these
equivalence-class resolution calls were actually dead from the point
where we changed the key for the rewrite-roots DenseMap over to
dependent types.
Rather than keying the rewrite tree roots on equivalence classes,
which imply a mapping through potential archetypes, key on (canonical)
types that are currently the anchors of equivalence classes.
Now that we no longer have DependentMemberTypes within the GSB that don't
have associated type declarations, we can no longer fail when
unpacking type into a RewritePath, so remove a bunch of optionals and
null Type checks that are now superfluous.
As part of minimization, example each rule to determine whether
minimizing the left-hand-side (while ignoring the rule under question)
still produces the right-hand side. If so, the rule is redundant and
will be eliminated from the rewrite tree.
Introduce the first step of a minimization algorithm for the
term-rewriting system used to produce anchors of equivalence
classes. This step simplifies the right-hand sides of each rewrite
rule, so that each rewrite step goes to the minimal result.
This code is currently not enabled; it *can* be enabled by minimizing
before computing anchors, but it ends up pessimizing compile times to
do so.
