This is going to make adding same-type and superclass requirement
failures might easier, because they only have to supply custom
diagnostic messages and substituted types.
Trade an extra copy for saving the cost of reinitialization when there
are a lot of witnesses to check. A small but measurable win when
type-checking the standard library.
Also add a test to make sure we still get the requirement environment
right for covariant 'Self'.
Having requirement kind encoded in the locator helps to identify
what kind of fix to generate (applicable to same-type, superclass)
without retrieving requirement itself.
Change logic to traverse the chain of declaration contexts
starting for "affected" declaration's parent and check if the
requirement is satisfied by one of them, if so return it as
requirement's declaration context.
Extract this logic into a method on `RequirementFailure` to make
it accessible for other types of requirement failure diagnostics.
This patch removes the need for Request objects to provide a default
cycle-breaking value, instead opting to return llvm::Expected so clients
must handle a cycle failure explicitly.
Currently, all clients do the 'default' behavior, but this opens the
possibility for future requests to handle failures explicitly.
When we fail to find a particular superclass type of a type in ill-formed
code, make sure that we were right to look here at all. This re-establishes
a check I had recently weakened.
Unresolved type attached to expressions may fail re-typechecking.
Also, disallow unresolved type in typeCheckCompletionSequence(). It doesn't
provide useful completions to developers.
rdar://problem/41224316
The name-lookup behavior that avoids looking for members of a nominal type
or extension therefore when resolving the inheritance clause is now
handled by UnqualifiedLookup, so remove it from the type checker itself.
Fixes rdar://problem/39130543.
`Fix` life-time is pretty limited as it is, and we'd have
to distinguish between standalone fixes and ones attached
to constraints, which is not worth the trouble.
Resolves: rdar://problem/43285774
I removed all uses of this in a previous pull request, but my
incorrect rebase onto master (following the introduction of
TypeResolverContext) left the flag there. Remove it again. NFC
The GenericSignatureBuilder and ConformanceLookupTable handle duplication
diagnostics for protocols that occur in the inheritance clause. Avoid
redundantly diagnosing these within checkInheritanceClause().
Rather than validating the signature of any declaration found by
name lookup, first check whether there is a collision on the full name
of the declaration. This should result in fewer declaration validations.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
