Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jckarter opened this issue Oct 25, 2016 · 6 comments
Assignees

Comments

@jckarter
Copy link
Member

@jckarter jckarter commented Oct 25, 2016

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
Copy link
Member

@DougGregor DougGregor commented Oct 25, 2016

@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
Copy link
Member Author

@jckarter jckarter commented Oct 25, 2016

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
Copy link
Member

@DougGregor DougGregor commented Oct 25, 2016

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
Copy link
Member Author

@jckarter jckarter commented Oct 25, 2016

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
Copy link
Member

@slavapestov slavapestov commented Dec 31, 2016

Hi Joe,

I fixed a couple of issues here:

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

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Apr 23, 2017

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

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants