* Use the presence of an argument type to check for associated values
hasOnlyCasesWithoutAssociatedValues returns true for any serialized
enum declaration whether or not it has cases. This never really came
up because it's mostly relevant to Sema's proto-deriving mechanism. Fix
this by using the presence of the case's argument type instead.
* Separate checks for presence of cases and enum simplicity
Necessary because the old behavior was an artifact of the
implementation.
We were putting conformance requirements on the representative of the
equivalence class, rather than directly on the potential archetype on
which the conformance requirement was specified. This violates the
invariant used when forming protocol-requirement sources that we never
reseat a requirement onto the representative (which would
have become a problem when implementing recursive protocol
constreaints) as well as masking a GSB idempotency issue that comes
from same-type requirements where the right-hand side was not
guaranteed to refer to the archetype anchor *within* that subcomponent.
Rather than true (an error occurred) or false (the constraint was
resolved), introduce ConstraintResult to better model what
happened. NFC for now, but the intent here is to report unresolved
constraints through this mechanism.
This function takes a member of a class and a base type, and returns
the correct 'self' type to substitute into the member's type.
When accessing a member of a subclass existential, if the member
was found via the superclass constraint, we have to erase the
existential down to the class type to calculate the member's
substituted type.
We already had special logic to handle class-constrained archetypes
in the callers of getSuperclassForDecl(); move this check into the
method, and add a similar check for subclass existentials, which
now support the getSuperclass() method.
The "superclass" of a subclass existential is the superclass
constraint. This makes a bunch of random things work, but is
somewhat unprincipled. It fits with how we already handle
class-constrained archetypes and DynamicSelfType, though.
Whether a protocol composition requires a class is no longer
solely a property of what protocols it contains; now, a
protocol composition consisting of a non-class constrained
protocol and a superclass should return true from requiresClass().
This is done by looking at the ExistentialLayout, instead of
walking the members directly.
Don't assume all members are existential types; we could have
a class (or a class-constrained existential) also, and this
needs to be handled.
When building a canonical protocol composition, the subclass
requirement always comes first in the list of types. This is
an important invariant allowing ExistentialLayout to be
calculated quickly.
Also, calculate the recursive properties of the composition
type from the recursive properties of its members, since they're
no longer trivial if the composition contains a class member
with generic parameters.
This consolidates calculations which need to look at every
protocol in an existential type. Soon we will also have to
deal with superclass constrained existentials, so start
updating call sites that look at all protocols to use the
new ExistentialLayout and correctly handle a class constraint
as well.
Also, eventually I will kill off the AnyObject protocol and
model it as a protocol composition with no protocols or
superclass, but the requiresClass() flag set.
This is not quite modeled this way yet and AnyObject still
exists, but the new abstraction is a step in the right
direction.
Specifically we only allow it as an argument to a TupleExpr and a ParenExpr and
can have the following forms:
(inject_into_optional (*_to_pointer ...))
or
(*_to_pointer ...)
This will allow for inout_to_pointer and array_to_pointer to be pattern matched
robustly and then special cased in SILGenApply.
The reason why these expressions need to be special cased is that they can
perform inout_expr accesses while going through code paths in SILGenApply where
it is expected that inout accesses do not occur.
rdar://29870610
This only affects the textual output, but should still improve the
experience when we /do/ hit one of these LLVM errors. In addition to
showing up better in Xcode, it'll also give us a proper
PrettyStackTrace because of the call to abort() instead of exit(1).
(There's a bit of finger-crossing that the act of printing the
diagnostic doesn't cause more errors. I only tested the fallback
path a little.)
The dependent type that is the subject of a ProtocolRequirement
source is independently computable based on the root potential
archetype of the source and the potential archetype to which the
requirement applies, i.e., it's just the dependent member type that
gets from the former to the later. Compute this directly, rather than
relying on the passed-down dependent type.
This is possible now because we no longer capriciously rebase
requirements onto the representatives of equivalence classes, nor
destroy any other structural information in the formation of potential
archetypes.
As we've done with layout requirements, introduce a new entry point
(addTypeRequirement) that handles unresolved type requirements of the
form `T: U`, resolves the types, and then can
1. Diagnose any immediate problems with the types,
2. Delay the type requirement if one of the types cannot be resolved,
or
3. Break it into one or more "direct" requirements.
This allows us to clean up and centralize a bunch of checking that was
scattered/duplicated across the GSB and type checker.
When we resolve() a type that is being used in a constraint, allow
that resolution to fail. If it does fail, then record the constraint
we were trying to address (via a stub that, currently, just drops it)
and continue on. NFC for now; this is intended to allow us to limit
the explosion of types in recursive systems.
We want to validate both type in same-type or conformance constraints,
even when the first type is ill-formed, so we don't leave null types
around for later phases to crash on.
Fixes rdar://problem/31093854.
All of this information is recoverable from the more-general,
more-sane signature conformances, so stop
recording/serializing/deserializing all of this extra stuff.
