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.

Sign up for GitHub

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

Jump to bottom

Refactor typeck code handling self and type parameters #4678

Closed
catamorphism opened this issue Jan 30, 2013 · 11 comments
Closed

Refactor typeck code handling self and type parameters #4678

catamorphism opened this issue Jan 30, 2013 · 11 comments
Labels
A-trait-system Area: Trait system A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@catamorphism
Copy link
Contributor

I'm about to land my patch for #3979, but @nikomatsakis suggested refactoring the code related to it more thoroughly in the future, in order to:

  • stop treating self specially, but rather, treat it like any other type parameter
  • don't concatenate bounds from different type parameters; rather, pass around vectors of vectors of bounds
catamorphism added a commit that referenced this issue Jan 30, 2013
@catamorphism
Handle supertrait calls in default methods
a30ea01 
Add a new method_super origin for supertrait methods. Also make
coherence create a table that maps pairs of trait IDs and self types
to impl IDs, so that it's possible to check a supertrait method
knowing only its index in its trait's methods (without knowing all
supertraits for a given trait).

r=nmatsakis and graydon -- with hope, we'll revamp all of this code as
per #4678, but for now this fixes the bug.

Closes #3979
@catamorphism catamorphism mentioned this issue Jan 30, 2013
Closed
@ghost ghost assigned catamorphism Feb 11, 2013
@catamorphism catamorphism mentioned this issue Feb 11, 2013
Closed
@brendanzab brendanzab mentioned this issue Feb 11, 2013
Closed
@catamorphism
Copy link
Contributor Author

I'm working on it. Moved up to 0.6 -- it doesn't look too hard (famous last words...)

@catamorphism
Copy link
Contributor Author

I need to talk to @nikomatsakis about this.

@nikomatsakis
Copy link
Contributor

Not critical for 0.6; removing milestone

@catamorphism
Copy link
Contributor Author

Nominating for milestone 5, production-ready

@graydon
Copy link
Contributor

graydon commented May 23, 2013

just a bug, removing milestone/nomination.

@huonw
Copy link
Member

huonw commented Jul 23, 2013

Visiting for triage; sounds like something that @msullivan might know something about.

@catamorphism
Copy link
Contributor Author

Sadly, I never got around to this. @nikomatsakis , have you perhaps already done this as part of another patch?

@flaper87
Copy link
Contributor

triage bump. There's still work to be done here. I think @eddyb did something already.

@japaric
Copy link
Member

japaric commented Nov 2, 2014

@nick29581 Can this issue be superseded by the planned work on UFCS (re: the self treatment part)?

@nrc
Copy link
Member

nrc commented Nov 2, 2014

Even with the UFCS work, self is still treated a bit specially in the compiler. It shouldn't be. So I think this issue is still relevant (maybe even more so) post-UFCS.

@nikomatsakis
Copy link
Contributor

I think this issue is basically done. We now have vectors-of-vectors (VecPerParamSpace) and we treat self like any other type parameter (it just happens to be in the Self space). At least the refactorings I suggested to Tim are done, anyway, so I'm going to close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-trait-system Area: Trait system A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@flaper87 @graydon @nikomatsakis @catamorphism @nrc @huonw @japaric