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.
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.
Validating a declaration can trigger conformance checking. If the conformance checker
comes across the same declaration as a candidate witness, it would fail to emit a
diagnostic. As a result we would then go onto SILGen, which would crash while emitting
a witness table with a missing entry.
Fixes <rdar://problem/45151902>.
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
- Many tests got broken because of two things:
- AST dump now outputs to stdout, but many tests expected stderr. This was a straightforward fix.
- Many tests call swift with specific parameters; specifically, many call `swift frontend` directly. This makes them go through the compiler in unexpected ways, and specifically it makes them not have primary files, which breaks the new AST dump implementation. This commit adds the old implementation as a fallback for those cases, except it dumps to `stdout` to maintain some consistence.
Finally, the `/test/Driver/filelists.swift` failed for unknown reasons. It seems its output now had some lines out of order, and fixing the order made the test pass. However, as the reasons why it failed are unknown, this fix might not have been a good idea. Corrections are welcome.
Associated type inference can synthesize type aliases with the same name
as a generic parameter. This is all fine since the underlying type of
the alias is the generic parameter type, however it might have been
synthesized in a constrained extension, resulting in bogus diagnostics
that depend on the order in which declarations are type checked, which
can vary between WMO and non-WMO, different batch mode settings, etc.
Instead, let's just check the generic parameter list first.
Fixes <rdar://problem/22587551>, <rdar://problem/44777661>.
We can use a cheaper check; instead of transforming both types and
replacing any type parameters with their anchors, instead just
check if both map to the same equivalence class.
This also fixes a bug, even though it shouldn't, but I'll take it.
Fixes <rdar://problem/35756206>.
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.
These two declarations are now equivalent:
protocol P : SomeClass { ... }
protocol P where Self : SomeClass { ... }
There's a long, complicated story here:
- Swift 4.2 rejected classes in the inheritance clause of a
protocol, but it accepted the 'where' clause form, even
though it didn't always work and would sometimes crash
- Recently we got the inheritance clause form working, and
added a diagnostic to ban the 'where' clause form, because
we thought it would simplify name lookup to not have to
consider the 'where' clause
- However, we already had to support looking at the 'where'
clause from name lookup anyway, because you could write
extension P where Self : SomeClass { ... }
- It turns out that despite the crashes, protocols with
'Self' constraints were already common enough that it was
worth supporting the existing behavior, instead of banning
it
Fixes <rdar://problem/43028442>.
An extension might have an extended nominal, even if the extended type
is an error type. This can happen if, for example, the type lookup was
ambiguous, because the declaration lookup more eagerly disambiguates.
This is fine, because even if we bind the extension to a nominal it's
okay to diagnose an error later. However, we do have to deal with this
case here by checking for an error type.
A better solution would be to ensure the extended type is always set
to something, even if we diagnosed an error while resolving it, because
we can always use the declared type of the extended nominal instead.
However when I tried that I ran into more problems, and I don't feel
like shaving this yak right now.
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
When forming the default witness table for a resilient protocol, look
for default associated conformances as well. These are identified by
associated conformance requirements whose root associated type has a
default type. For such requirements, we look for a conformance and
record it as a default associated conformance.
Emit a warning in cases where we don't find such a conformance,
because the associated type and conformance *may* have been added
with the intent of being resilient, and we can't know. This warning
might be a terrible idea, but it is only enabled under
-enable-resilience (which itself is hidden) and fires in one only
place in the standard library (which seems legitimate), so we'll try
it for now.
@_nonoverride is the opposite of override, disabling all override checking
for the given declaration. This can be used to suppress diagnostics related
to declarations that are almost overrides but shouldn’t be or to
intentionally break the override chain; in each case, we’ll end up with
an overload rather than an override.
