Skip to content

refactor how impl self type vs iface type is stored (at least for classes) #2434

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

Closed
nikomatsakis opened this issue May 24, 2012 · 1 comment
Labels
A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Milestone

Comments

@nikomatsakis
Copy link
Contributor

Near as I can tell, this is how things stand now:

  • Both impls and classes make use of an iface_ref, which has an id, a path and so forth
  • The type that the iface_ref refers to is stored in the node_types table under the id of the iface_ref
  • (So far this all makes sense)

But this is where things go off the rails.

  • For impls, the self type is stored in the tcache under the item id.
  • For classes, the self type seems to be stored in the tcache under the iface_ref's id.

(This is based on the "impl_id" that is stored in resolve.)

The idea of encapsulating an iface+impl pair into an iface-ref seems to make sense, but we probably want to either use separate tables to store the self type (i.e., not the tcache) or else use a separate id. Right now classes end up with different types in the tcache table and node_types table under the same ID. This seems unusual and I think it is the only place that it occurs.

Also, impls + classes should be as similar as possible. I think this was the original idea of introducing iface-ref, but there still seem to be some significant differences in how things work between the two. So we should erase that.

@catamorphism
Copy link
Contributor

Any differences between impls and classes that were introduced by me were for expedience (as I saw it at the time), not by design, so I definitely support simplifying the code in any way possible. (I'm on vacation until Tuesday, so, whoever gets to it first...)

@ghost ghost assigned catamorphism Jun 7, 2012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
ui_test: build dependencies in locked mode unless bless is enabled

This should help ensure that tests are reproducible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

No branches or pull requests

2 participants