Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Detect that failed requirement comes from contextual type and use
that information to determine affected declaration.
Resolves: rdar://problem/47980354
We generated a mix of "inferred" and "nested type name match"
constraints for the case where we had two nested types with the same
name and inferred that they are equal. Make them consistent by always
using nested type name match constraints. This fixes a bug where we
would get different canonical generic signatures in different source
files because we inferred the same-type constraint with different
requirement sources.
Fixes rdar://problem/48049725.
If affected declaration is a static or instance memeber (excluding
operators) and failed requirement is declared in other nominal type
or extension, diagnose such problems as `in reference` instead of
claiming that requirement belongs to the member itself.
Extend existing `RequirementFailure` functionality to support
conditional requirement failures. Such fixes are introduced
only if the parent type requirement has been matched successfully.
Resolves: rdar://problem/47871590
When we aren't going through proper resolution of an associated type
of 'Self', at least record an archetype anchor. Narrow fix for
rdar://problem/47605019.
This reverts commit c725660cc9. It
uncovered a use-after-free in the GenericSignatureBuilder. Apologies
for the lack of a test case here; I'm still looking for something
small enough to commit.
Fixes rdar://problem/46772328.
Under -debug-generic-signatures, we were computing and emitting
conformance access paths for one test. Given that conformance access
paths are used ubiquitously now, this test isn't providing any value
(nor is the debug dump), stop dumpoing them.
Instead of trying to order based on the "nested depth", let's
always prefer canonical ordering of type parameters when it comes
to picking representative equivalence class.
Resolves: rdar://problem/45957015
In the stuctural type resolution stage we don't have enough information
to check conformance and same-type requirements involving type
parameters, so we would just ignore such requirements, assuming they
will be checked later in the interface stage.
However, there was a case where we would return an error type without
emitting a diagnostic, assuming that at least one other requirement
fails. If a TypeLoc has an error type we don't resolve it again in
the interface type stage. So we would end up with an error type and
no diagnostic.
Fix this by not checking generic arguments in the structural stage at
all; we will do the complete check in interface stage, where we know
how to check everything and emit all the right diagnostics.
Fixes <rdar://problem/45271500>.
It's mostly redundant, we already have TypeBase::isExactSuperclassOf().
The only difference between the two is that the TypeChecker method
admitted self-conforming class-constrained existentials (like C & P
where P is an @objc protocol with no static methods) as subclasses
of themselves.
This was actually not sound in the general case, because you can
call static methods and required initializers on the *class* C,
so I'm going to unilaterally ban this, but since the importer
creates such types, I have to allow it if the class is an
imported class.
In structural lookup mode, let's resolve protocol typealiases to
dependent member types also. This is because areSameType() has
no way to see if a type alias is going to be equal to another
associated type with the same name, and so it would return false,
which produced ambiguity errors when there should not be any.
This exposes a deficiency in how we diagnose same-type constraints
where both sides are concrete. Instead of performing the check on
the requirement types, which might be dependent member types that
later on resolve to concrete types, do the check on the actual
equivalence classes further down in the GSB instead.
However, this in turn produces bogus diagnostics in some recursive
cases where we add same-type constraints twice for some reason,
resulting in a warning the second time around. Refine the check by
adding a new predicate to FloatingRequirementSource for requirements
that are explicitly written in source... which is not what
isExplicit() currently means.
We were building the following constraint, where $member and
$input are type variables and 'result' is a concrete type:
- Conversion($member, $input -> result)
When $member was fixed to a function type of arbitrary
arity, this would simplify to a conversion between $member's
result type and 'result'.
Instead, express this using the newly-added FunctionResult
constraint:
- FunctionResult($member, $result)
- Conversion($result, result)
I wasn't expecting this to change diagnostics, but it looks
like it did; I'm not going to bother investigating why,
because Pavel is going to rewrite contextual diagnostics soon
anyway. All but one are clear improvements.
Fixes <rdar://41416346> and <rdar://41416647>, two cases where
diagnostics regressed from -swift-version 3 to -swift-version 4.
Extend the inputs to InheritedTypeRequest, SuperclassTypeRequest, and
EnumRawTypeRequest to also take a TypeResolutionStage, describing what
level of type checking is required. The GenericSignatureBuilder relies
only on structural information, while other clients care about the
full interface type.
Only the full interface type will be cached, and the contextual type
(if requested) will depend on that.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
Previously we would just ignore generic arguments when applied to a
member type of a type parameter base. This was fine as long as we would
always do a final pass over a function's signature with the archetype
resolver, but when that goes away we have to check the generic arguments
here.
Most of the time, this is an error, unless the member type is a type
alias with generic parameters.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
When we determine that an optional value needs to be unwrapped to make
an expression type check, use notes to provide several different
Fix-It options (with descriptions) rather than always pushing users
toward '!'. Specifically, the errors + Fix-Its now looks like this:
error: value of optional type 'X?' must be unwrapped to a value of
type 'X'
f(x)
^
note: coalesce using '??' to provide a default when the optional
value contains 'nil'
f(x)
^
?? <#default value#>
note: force-unwrap using '!' to abort execution if the optional
value contains 'nil'
f(x)
^
!
Fixes rdar://problem/42081852.
