* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
While trying to diagnose a problem related to contextual result type
of the trailing closure, don't assume that declaration context is properly
set, instead directly set it to correct one before running type-check.
Resolves: rdar://problem/35699666
The enclosing conformance-lookup operation can fail (i.e., it returns
Optional), but the nested call was force-unwrapping the optional from
an inner call for no particular reason. Stop doing that, which fixes
SR-6466.
Note that the offending code is still something that should go away in
time, so this is merely polishing the band-aid to avoid a crash that
occurs often with conditional conformances.
When we substitute into an inherited conformance, make sure that we
follow the superclass chain from the new conforming type up to the
matching superclass *before* doing the substitution.
Fixes rdar://problem/35632543.
Fixes a former crasher that included well-formed code that was rejected
by my previous refactoring. Said crasher now passes, and IRGen's properly
as well. Also, account for three more fixed crashers.
If unqualified name lookup finds an associated type, but resolution to
the type witness fails, produce a diagnostic rather than silently
failing. Fixes the crash in SR-5825, SR-5881, and SR-5905.
It's conceivable that we could resolve this with suitably global
associated type inference... but that's far off and it's best not to
crash until then.
The various _*Indexable protocols only exist to work around the lack of
recursive protocol constraints. Eliminate all of the *_Indexable protocols,
collapsing their requirements into the corresponding Collection protocol
(e.g., _MutableIndexable —> Collection).
This introduces a number of extraneous requirements into the various
Collection protocols to work around bugs in associated type
inference. Specifically, to work around the lack of "global" inference
of associated type witnesses. These hacks were implicitly present in
the *Indexable protocols; I've made marked them as ABI FIXMEs here so
we can remove them when associated type inference improves.
Fixes rdar://problem/21935030 and a number of ABI FIXMEs in the library.
CSDiag was misinterpreting the result of checkGenericArguments().
A result of SubstitutionFailure does not mean a diagnostic was
emitted, only a result of Failure means that. This fixes a case
where we did not emit a diagnostic, result in a crash on invalid.
The diagnostic is still poor, but that's better than crashing.
Fixes <https://bugs.swift.org/browse/SR-5932>,
<rdar://problem/34522739>.
We are currently in process of removing `InOutType`
so `VarDecl::get{Interface}Type` is going to wrap base
type into `InOutType` if its flag indicates that it's
an `inout` parameter declaration. But such type can't
be restored directly using `VarDecl::set{Interface}Type`
caller needs additional logic to extract base type.
Resolves: rdar://problem/33613329
Arguments and parameters are not guaranteed to line-up perfectly,
because failure diagnostics sometimes has to match one argument
to different "candidate" parameters to see which one is closer,
so let's teach `computeDefaultMap` to respect that.
Resolves: rdar://problem/33433087.
When we detect that a requirement source is self-derived, identify the
redundant subpath and remove it to produce a new, smaller requirement
source that computes the same result. We were doing this form the
limited case where the redundant subpath ended at the end of the
requirement source; generalize that notion.
Fixes SR-5601.
We break name lookup circularities by special-casing validation of
type aliases, resolving the underlying type of the type alias before
building the generic environment of the protocol that contains the
type alias.
However doing this gives the type alias an underlying type written
in terms of unresolved DependentMemberTypes which do not map to
associated types.
Attempting to substitute such a type fails.
We worked around this by re-validating type alias members of
protocols when we finally got around to building the protocol's
generic environment. Force this to happen earlier in
substMemberTypeWithBase(), because we need the fully resolved
underlying type in order to perform the substitution.
Also, fix TypeAliasDecl::setUnderlyingType() to only create a new
NameAliasType the first time it is called. In this special case
where it can be called twice with a resolved underlying type the
second time, we should not be creating a new NameAliasType.
There are better fixes possible here, requiring various levels
of refactoring. I'll investigate this soon, but for now this narrow
fix should address the problem with minimal risk.
Fixes <rdar://problem/33189068>.
While trying to validate Objective-C keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33044867
The change to roll back a part of SE-0110 to allow multi-argument
functions to be passed in places where functions taking a tuple are
expected resulted in a regression in some cases where the fix would
strip off the last ParenType from single-argument functions.
Instead of stripping off parens from both function types we're trying to
match when they both have them, strip off none. This ensures that we
don't get summarily rejected in the nested matchTypes call by other
SE-0110-related code that bails if the two types do not have the same
"parenness".
Fixes rdar://problem/33043106 / SR-5387.
This reverts commit 70deaa89e2.
My next commit already added the same test case, but this reverted
commit added it in a way that the test will fail with my fix in place.
If we encounter an associated type reference within a concrete type, but
haven't seen a specific protocol requirement, add the protocol
conformance.
Fixes rdar://problem/33139928 and another crasher.
While trying to diagnose problems related to keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33135487
- Deinitializers never get a custom Objective-C name.
- Classes and protocols are never bridged themselves; that only matters
for structs and enums.
This avoids another circularity issue like the one in a8bc132565,
where the Clang importer ends up importing a class and hands it to the
type checker, which then asks about conformances. The conformance
lookup table goes to add the extension from the Swift module, except
that the Swift module is what asked for the import in the first place.
It's possible there's a more general solution here, but this
particular change is good even in the non-crashy cases, and definitely
safe for Swift 4.0. Even if the test case is even more idiosyncratic
than the last one.
The test case change for SourceKit is probably due to the first
category not triggering the import of the other two
categories. Changes in import order have been known to affect source
compatibility, though not frequently. However, categories are not
intended to be ordered in the first place. There's still more we can
do in this space, and implicitly depending on these calls /outside/ of
the importer to control category import order was quite brittle
anyway.
SR-5330 / rdar://problem/32677610
Fixes crasher in diagnostics related to the fact that contextual type
is not always available when trying to diagnose problems related to
calls with trailing closures.
Resolves: rdar://problem/33067102
The small-but-significant change to the generic signature builder is
to refuse to create unresolved potential archetypes. Instead, delay
any requirement that depends on such type, to be reprocessed once
we've seen all of the other requirements. If the type can be resolved
later, it will be; Otherwise, the type checker will complain when it
sees an unresolvable type. By itself, this fixes the crash in SR-2796.
Doing this by itself regresses diagnostics because typo correction in
the generic signature builder no longer kicks in. Therefore, implement
typo correction for these cases in the type checker proper, using its
existing facilities for typo correction. The result is more consistent
code with a better result.
Fixes SR-2796 / rdar://problem/28544316.
When a concrete requirement is invalid due to the concrete type
lacking a conformance to a particular, required protocol, don't emit
that incorrect requirement---it causes invalid states further down the
line.
Fixes SR-5014 / rdar://problem/32402482.
While here, fix a comment that Huon noticed trailed off into oblivion.
When we see two type(aliase)s with the same name in a protocol
hierarchy, make them equal with an implied same-type requirement. This
detects inconstencies in typealiases across different protocols, and
eliminates the need for ad hoc consistency checking. This is a step
toward simplifying away the need for direct-diagnosis operations
involving concrete type mismatches.
While here, warn when we see an associated type with the same as a
typealias from an inherited protocol; in this case, the associated
type is basically useless, because it's going to be equivalent to the
typealias.
Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:
* Always store a ProtocolConformanceRef in via-superclass and
via-concrete requirement sources, so we never lose this information.
* When concretizing a nested type based on its parent, use the
via-concrete conformance information rather than performing lookup
again, simplifying this operation considerably and avoiding
redundant lookups.
* When adding a conformance requirement to a potential archetype that
is equivalent to a concrete type, attempt to find and record the
conformance.
Fixes SR-4295 / rdar://problem/31372308.
When an archetype conforms to a protocol abstractly (ie, it is
not class-constrained and we don't have any further information
other than that it conforms), we can recover nested types,
but we cannot recover the conformance of those nested types
to protocols if those conformances are concrete (the nested
type might be concrete, or it might be a class-constrained
archetype).
To work around this, we added a hack where if the conformance
lookup in the SubstitutionMap fails, we fall back to the module.
This is horrible and unprincipled, but has to remain in place
until more infrastructure is plumbed through.
Commit 620db5f74c made this
workaround apply in fewer cases, so that we could still catch
cases where the SubstitutionMap was constructed with missing
conformances.
Unfortunately this workaround didn't handle the case where the
nested type was an archetype with a superclass constraint.
This will all go away soon, but for now tweak the logic a bit,
since I really want to keep the "narrow" workaround in place
and not the general fallback, otherwise we run the risk of
SubstitutionMap conformance lookup bitrotting completely.
Fixes <https://bugs.swift.org/browse/SR-4088> and
<rdar://problem/32773028>.
Rather than performing typo correction at the very end of finalize(),
do it as part of delayed requirement handling when we cannot otherwise
make progress. This is a cleaner way to cope with typo correction that
gives us a better chance of getting to a sane result.
Fixes rdar://problem/31048352 by eliminating the need for tracking the
number of unresolved potential archetypes altogether. Fixes
rdar://problem/32077627.
Validation for typealiases in protocols is... odd. It needs to avoid
depending on the whole protocol being validated, so it does an initial
validation that can leave nested types of Self (and other associated
types) somewhat unresolved. In these cases, do something icky but
partially effective: when we resolve the protocol, go back and clean
up the types of these typealiases.
A better solution would allow us to use the types of these typealiases
within the Generic Signature Builder without recording them in the AST
as "the interface type", so there's no way unresolved nested types
could be found (and, therefore, nothing to "fix up" later). Howwever,
that's a more significant undertaking.
Fixes rdar://problem/32287795.
ConstraintSolver::coerceToRValue() missed a bunch of cases where we
should be dealing with lvalues, e.g., tuples, "try" expressions, and
so on. Extend TypeChecker::coerceToRValue() to deal with the
expression type side-tables and ConstraintSolver::coerceToRValue() to
it.
Fixes rdar://problem/32700180, a crash-on-valid.
