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.
Implements the minimum specified by the SE-proposal.
* Add the CaseIterable protocol with AllCases associatedtype and
allCases requirement
* Automatic synthesis occurs for "simple" enums
- Caveat: Availability attributes suppress synthesis. This can be
lifted in the future
- Caveat: Conformance must be stated on the original type
declaration (just like synthesizing Equatable/Hashable)
- Caveat: Synthesis generates an [T]. A more efficient collection
- possibly even a lazy one - should be put here.
Previously, the following code would result in different sets of
conditional requirements:
struct RedundancyOrderDependenceGood<T: P1, U> {}
extension RedundancyOrderDependenceGood: P2 where U: P1, T == U {}
struct RedundancyOrderDependenceBad<T, U: P1> {}
extension RedundancyOrderDependenceBad: P2 where T: P1, T == U {}
The T: P1 requirement is redundant: it is implied from U: P1 and T == U,
but just checking it in the signature of the struct isn't sufficient,
the T == U requirement needs to be considered too. This uses a quadratic
algorithm to identify those cases. We don't think the quadratic-ness is
too bad: most cases have relatively few requirements.
Fixes rdar://problem/34944318.
To make generic signature builder more robust it's imperative to
eliminate possibility of out-of-order typealias substitution.
These changes try to make it so potential archetypes could only be
constructed with associated types by doing early concrete type (typealias)
subsitution while trying to resolve equivalence class.
During "expansion" of the requirements of a protocol, we check all of
the inherited associated types against definitions within the
protocol. Also look for concrete types within extensions of that
protocol, so we can identify more places where developers have used
typealiases in inheriting protocols to effect a same-type constraint
on an inherited associated type.
Fixes SR-7097 / rdar://problem/38001269.
It turns out that we need to have the diagnostic consumers set up
before we've actually opened the input files, which makes sense
because we might want to emit diagnostics about not being able to open
an input file. Switch to using file names instead, and mapping those
over to source ranges only once we actually need to handle a
diagnostic with a valid source location.
If a top-level diagnostic is in a particular source range, the
RangeSpecificDiagnosticConsumer will funnel it and any attached notes
to a particular "sub-consumer" designated for that range (intended to
be used with whole files). If it's not in a range designated for any
sub-consumer, the diagnostic is passed to all registered
sub-consumers.
This is intended to be used for batch mode, so that diagnostics that
are definitely associated with a particular file can be emitted in
that file's .dia output, while diagnostics that may be associated with
other files (such as those that come from Clang) will still get
presented to the user.
Improve support for Optional among other things.
Return Any when it is really the best answer given the types involved,
or nullptr if we cannot yet produce an accurate result.
This implementation returns Any? when joining Any with an
Optional<T>. In our type system both Any and Any? are effectively
subtypes of one another since each can hold all the values that the
other can hold. So this choice is somewhat arbitrary, but does line up
nicely with the notion that T is always a subtype of T?.
Conformances that discoverably for a type parameter via a superclass
requirement occupy a bit of a gray area in the type checker and
generic signature handling right now: we have a type parameter (so the
paths that handle concrete conformances don't kick in), but the
conformance itself isn't modeled as a requirement because it is
available via lookup. Teach SubstitutionMap's conformance lookup to
detect this case and perform conformance lookup in the generic
signature (i.e., falling back to global lookup) in this case,
replicating the hack that IRGen uses to address the same issue when
accessing the conformance (see GenArchetype.cpp's TODO where we lookup
a conformance on the superclass). The removal of that hack (as well as
this one) are tracked by rdar://problem/34609744.
For now, fixes SR-7072 / rdar://problem/37904576.
The key path pattern needs to include a reference to the external descriptor, along with hooks for lowering its type arguments and indices, if any. The runtime will need to instantiate and interpolate the external component when the key path object is instantiated.
While we're here, let's also reserve some more component header bytes for future expansion, since this is an ABI we're going to be living with for a while.
Mark Lacey
Mark Lacey
Huon Wilson
Doug Gregor
Sho Ikeda
Slava Pestov
Robert Widmann
Huon Wilson
Pavel Yaskevich
Arnold Schwaighofer
Graydon Hoare
Jordan Rose
Xi Ge
Stephan Tolksdorf
Joe Groff
Graydon Hoare