[SR-3045] Compiler doesn't correctly handle type declarations with eliminated type parameters

[jckarter]

Previous ID	SR-3045
Radar	None
Original Reporter	@jckarter
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: ef3a5ad18502b4610ec6586b03f8062a

Issue Description:

The T parameter in the class C below is eliminated by the subsequent T == U.T same-type constraint:

protocol P {
  associatedtype T
}

class C<T, U: P> where T == U.T {}

Accepting this signature leads to downstream problems with things like the specializer. For example, with a signature like this:

protocol Q {}
protocol P {
  associatedtype T: Q
}

class C<T: Q, U: P> where T == U.T {}

generic signature canonicalization eliminates the redundant T: Q requirement from the top-level signature, but T can still appear in type contexts that require Q, and functions like Substitution::subst fail to anticipate these non-canonical generic signatures and fail to find the T: Q conformance via the same-type constraint.

[DougGregor]

@slavapestov loosened these restrictions as part of supporting extensions of concrete types, e.g.,:

extension Array where Element == String { ... }

It's plausible that we could reject some instances of this, but I'm not sure that we should. Rather, we need to finish fixing `Substitution::subst` et al.

[jckarter]

OK. We could still perhaps warn or error on a type or function declaration that introduces type variables that are always redundant, though with constrained extensions I guess we'd still end up having to digest this kind of generic signature downstream.

[DougGregor]

Yeah, and I've seen some cases of developers doing this simply so they have a shorter name for `T.AssocType1.AssocType2` to use in their signature.

[jckarter]

Another legit use case I encountered while investigating emaloney (JIRA User)'s project is this kind of thing:

class Foo<T, U: P> where U.V == SomeGeneric<T, Int>

where the type parameter T is always determined by U.V, but the intent is to require U.V to be a parameterization of SomeGeneric.

[slavapestov]

Hi Joe,

I fixed a couple of issues here:

• slavapestov@edadba7

• slavapestov@623755d

Do you have any test cases for this problem? No doubt there are problems remaining but I don't have any concrete repros.

[slavapestov]

Closing this – if we get more test cases that fail, we can file more specific bugs.