This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
Another pile of changes to use a side map for types in the constraint
solver and only write them directly into expressions once we have a
known good solution that we want to apply.
Still incomplete, we continue to write the types into expressions along
the way at the moment.
First, add some new utility methods to create SubstitutionMaps:
- GenericSignature::getSubstitutionMap() -- provides a new
way to directly build a SubstitutionMap. It takes a
TypeSubstitutionFn and LookupConformanceFn. This is
equivalent to first calling getSubstitutions() with the two
functions to create an ArrayRef<Substitution>, followed by
the old form of getSubstitutionMap() on the result.
- TypeBase::getContextSubstitutionMap() -- replacement for
getContextSubstitutions(), returning a SubstitutionMap.
- TypeBase::getMemberSubstitutionMap() -- replacement for
getMemberSubstitutions(), returning a SubstitutionMap.
With these in place, almost all existing uses of subst() taking
a ModuleDecl can now use the new form taking a SubstitutionMap
instead. The few remaining cases are explicitly written to use a
TypeSubstitutionFn and LookupConformanceFn.
Fix a couple of places where we were not managing to consider
redundant constraints as 'redundant', so the canonicalized generic
signatures were not in fact minimal. Address this in several places:
* When a type is made concrete, any superclass requirements on it are
redundant
* When a type is made concrete, any same-type relationships among its
nested types are redundant
* Only emit potential-archetype-to-concrete constraints in the
resulting signature for the component anchors; not for every type.
The first two bullets were existing problems that are now fixed; the
last is something I appear to have introduced with last week's
refactoring of canonicalized same-type constraints.
The recent work to make the canonicalization deterministic exacerbated
the issue considerably, leading to huge blow-up in the size of
canonical generic signatures that cost ~100k in standard library
size. This change recovers that 100k.
The canonicalization of dependent member types had some
nondeterminism. The root of the problem was that we couldn't
round-trip dependent member types through the archetype
builder---resolving them to a potential archetype lost the specific
associated type that was recorded in the dependent member type, which
affected canonicalization. Maintain that information, make sure that
we always get the right archetype anchor, and tighten up the
canonicalization logic within a generic signature.
Fixes rdar://problem/30274260 and should unblock some other work
that depends on sanity from the archetype builder and generic
signature canonicalization.
When requesting a nested type of a potential archetype, the archetype
builder was immediately jumping to the representative of the (parent)
archetype. However, this means that we completely lost the structure
of the incoming types... one you ask for "U.AssocType" and end up with
"T.AssocType". Worse, the "representative" can vary based on the
ordering of constraints (particularly, same-type constraints), which
means that the resulting type would be somewhat unstable.
Stop doing that. When asking for a nested type, always return a type
nested within the given potential archetype, setting up the
appropriate same-type constraints with the representative's
corresponding nested type.
This is necessary when we want to differentiate between type reference
on extension declaration's start, e.g "extension A {}", and other
references of "A". NFC on existing functionality.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
It was checking the wrong predicate, and therefore failing to mark
inherited default arguments as actually being inherited.
While here, explicitly clear out default arguments from non-inherited
cloned parameter lists. I don't think this case can come up today, but
it's better to be correct when we do hit it.
rdar://problem/30167924
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
We sometimes construct DependentMemberTypes with an UnresolvedType
base. These are not "real" interface types and can end up in
places where we don't expect interface types, triggering an
assertion. Make sure such types don't respond true to hasTypeParameter().
We must order protocol typealiases *after* other types, so that
if a protocol typealias is equal to an associated type, the
representative is chosen to be the associated type and not the
typealias.
Fixes <https://bugs.swift.org/browse/SR-3687> and
<rdar://problem/30118513>.
Separate formal lowered types from SIL types.
The SIL type of an argument will depend on the SIL module's conventions.
The module conventions are determined by the SIL stage and LangOpts.
Almost NFC, but specialized manglings are broken incidentally as a result of
fixes to the way passes handle book-keeping of aruments. The mangler is fixed in
the subsequent commit.
Otherwise, NFC is intended, but quite possible do to rewriting the logic in many
places.
IndexSwiftASTWalker::initVarRefIndexSymbols wasn't handling getCurrentExpr() returning a nullptr
as it does when processing a reference to someVar in the below import:
import var SomeModule.someVar
This patch fixes rdar://problem/30118572 and adds tests for import var/func references.
This is a generic signature that stores exactly the requirements that a
protocol decl introduces, not letting them be implied by the Self :
Protocol requirement, nor storing any requirements introduced by the
protocols requirements.
Specifically, suppose we have
protocol Foo {}
protocol Bar {}
protocol Baz {
associatedtype X : Foo
}
protocol Qux: Baz {
associatedtype X : Bar
}
The normal generic signature and (canonical) protocol requirement
signature of `Baz` will be, respectively
<Self where Self : Baz>
<Self where Self : Baz, Self.X : Foo>
And for `Qux`, they will be:
<Self where Self : Qux>
<Self where Self : Qux, Self : Baz, Self.X : Bar>
Note that the `Self.X : Foo` requirement is not listed.
For the moment, this is unused except for `-debug-generic-signatures`.
Conformances for an associated type might be attached to any
same-named associated type of the parent, so search those as
well. Overally, this is a fairly expensive search, and there is likely
a better architectural solution that will require some refactoring of
SubstitutionMap.
When two associated types with the same name are on the same dependent
type T, introduce a same-type constraint between the the corresponding
potential archetypes. This eliminates ordering dependencies in the
archetype builder.
Fixes the reduced test case from rdar://problem/23149063, but doesn't
fully address the idea that we should be tracking associated type
redeclarations in a meaningful way.
Make the "archetype anchor" algorithm use the same total order used to
compare dependent types in a generic signature, so that it is a
dependable total order. Tighten up the compareDependentTypes() logic
(and checking of it) a bit now that it's being used more frequently.
The weird code around GenericSignature::isCanonicalTypeInContext() is
due to a longstanding issue where
ArchetypeBuilder::resolveArchetype(t)->getDependentType()
is not the identity function when the incoming type is a
DependentMemberType with known associated types. We want to establish
this behavior at some point going forward, in which case we can go
back to the prior implementation of
GenericSignature::isCanonicalTypeInContext().
