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

After libsyntax, idents should be replaced by Names #6993

Closed
jbclements opened this issue Jun 7, 2013 · 20 comments · Fixed by #28642
Closed

After libsyntax, idents should be replaced by Names #6993

jbclements opened this issue Jun 7, 2013 · 20 comments · Fixed by #28642
Labels
A-parser Area: The parsing of Rust source code to an AST A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-syntaxext Area: Syntax extensions C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@jbclements
Copy link
Contributor

This is a FIXME issue; right now, an ident contains information used by expansion. After expansion, this is collapsed down to a single Name (an index into the interner). However, the downstream stuff in librustc refers to "ast::ident" everywhere. It would save space and time to just pass around one int rather than two, by replacing uses of "ident" with "Name". I don't know if I'll have time to do this. (Planning for my untimely demi^H^Hparture.)

@jbclements
Copy link
Contributor Author

More details on the "right way" to fix this.

resolve.rs, generally speaking, builds tables and then resolves identifiers by looking things up in them. Sometimes, this lookup should respect renamings (e.g. lexical bindings). Other times, it shouldn't (e.g., module names).

during expansion, identifiers gain "syntax contexts"; at the end of expansion, each ident has a uint telling what name it started with, and what syntax context it occurred in. There's an operation called mtwt_resolve (that is, the "resolve" operation specified in the MTWT paper) that maps this to a new name.

Ideally, then, this mtwt_resolve would be called when building the tables of lexical bindings, and not called otherwise. This would probably be done by having most of the tables just map Names (that is, uint indexes into the interner) to whatever-it-is-they-map-to.

Currently, however, these tables all map idents to whatever-it-is. I should fix this, but frankly, I'm just scrambling to get through, so I'm taking the short-cut of using the existing data structure rather than updating them.

@pnkfelix
Copy link
Member

For those following along, "the MTWT paper" presumably refers to "Macros That Work Together"

@bblum
Copy link
Contributor

bblum commented Aug 19, 2013

AIUI this is just an internal cleanup and possible performance issue. Nominating for no milestone; let's see if the triage committee agrees.

@pnkfelix
Copy link
Member

(For what it's worth, I don't think "nominating for no-milestone" explicitly via the I-nominated tag for an Issue that already has no milestone is an appropriate use of the nomination protocoll. More specifically, IMO the triage committee should only be looking at tickets that need their milestone setting changed and where there exists some champion for that change. @graydon any thoughts on process here?)

@graydon
Copy link
Contributor

graydon commented Aug 20, 2013

Yeah, nomination means you think the milestone assignment should change. Removing label.

bors added a commit that referenced this issue Sep 10, 2013
update AST so that ExprBreak and ExprCont expressions contain names, not idents. Fixes #9047 and makes progress on #6993. Simplifies the compiler very slightly, should make it (infinitesimally) faster.
@emberian
Copy link
Member

Triage: still a bunch of work to do on this.

flaper87 added a commit to flaper87/rust that referenced this issue Feb 11, 2014
@flaper87 flaper87 self-assigned this Feb 11, 2014
@flaper87
Copy link
Contributor

I started working on this, I'll keep doing so!

@ahmedcharles
Copy link
Contributor

Is anyone still working on this?

@jbclements
Copy link
Contributor Author

I'm going to be working on macros again for a month, starting in a few weeks. I guess that qualifies as a "yes".

@bgamari
Copy link
Contributor

bgamari commented Jul 6, 2014

Any updates here?

@jbclements
Copy link
Contributor Author

I'm working on hygiene, but not this specific issue. Still looks like a nice fix.

@emberian
Copy link
Member

Looking through a git grep Ident librustc*, it seems this is pretty close to being done.

@petrochenkov
Copy link
Contributor

I'm working on this.
So far I see two subtasks to work on:

  • There's a bunch of random code everywhere using Idents unconsciously, it can be rewritten to work with Names unconditionally and without much doubt.
  • Some parts of resolve (all code calling mtwt::resolve) legitimately need SyntaxContext information from Idents to resolve hygienic names. So, HIR has to keep at least some information about macro expansion despite the general desire to get rid of it. The good news is that many structures in HIR (at least TraitRef, Generics, TyPath, PatStruct, ExprStruct, PatEnum, PatQPath, but not ExprPath) can drop syntax context information at cost of splitting hir::Path into hir::NamePath and hir::IdentPath (with Name and Ident segments respectively) and some duplication in resolve in code performing path resolution. This duplication can be considered a drawback, so this subtask is not as unambiguous as the previous one. I'd be glad to hear some opinions on this matter.

I'll likely submit two separate PRs to cover these two tasks in order.

@petrochenkov
Copy link
Contributor

HIR visitors are somewhere between these two tasks, but I tend to convert them to use Names. The logic is that syntax context information is needed for very narrow task in resolve and is not supposed to be used by general visitors.

@arielb1
Copy link
Contributor

arielb1 commented Sep 17, 2015

@petrochenkov

We may want to move resolve to the AST.

@petrochenkov
Copy link
Contributor

@arielb1
At least the first my subtask doesn't prevent this move.
(Considering the second one, I'll try to do it anyway just to see what will come of it)

@petrochenkov
Copy link
Contributor

cc #28139 @nrc

@jbclements
Copy link
Contributor Author

Somewhat off-topic, but I'd love to come up to Mountain View and talk about Macros 2.0 some time.

@nrc
Copy link
Member

nrc commented Sep 22, 2015

@petrochenkov I'd be strongly against splitting Paths in the manner you suggest, I'd much rather just carry around a little extra redundant information than have to deal with that.

@jbclements we haven't made much progress with macros 2.0 tbh, I'll be sure to ping you once we get stuck in.

bors added a commit that referenced this issue Sep 23, 2015
Part of #6993

This patch replaces `Ident`s with `Name`s in data structures of HIR and updates the dependent crates to compile and pass `make check`.
Some HIR structures still use `Ident`s, namely `PathSegment`, `PatIdent`, `ExprWhile`, `ExprLoop`, `ExprBreak` and `ExprAgain`,  they need them for resolve (but `PathSegment` is special, see #6993 (comment)).

r? @nrc
@petrochenkov
Copy link
Contributor

@nrc

I'd be strongly against splitting Paths in the manner you suggest, I'd much rather just carry around a little extra redundant information than have to deal with that.

I've just tried to do it and it indeed turned out to be too much trouble for the little expected gain. I'll omit this part. The second PR will just remove some remaining random Idents.

bors added a commit that referenced this issue Sep 26, 2015
This PR removes random remaining `Ident`s outside of libsyntax and performs general cleanup
In particular, interfaces of `Name` and `Ident` are tidied up, `Name`s and `Ident`s being small `Copy` aggregates are always passed to functions by value, and `Ident`s are never used as keys in maps, because `Ident` comparisons are tricky.

Although this PR closes #6993 there's still work related to it:
- `Name` can be made `NonZero` to compress numerous `Option<Name>`s and `Option<Ident>`s but it requires const unsafe functions.
- Implementation of `PartialEq` on `Ident` should be eliminated and replaced with explicit hygienic, non-hygienic or member-wise comparisons.
- Finally, large parts of AST can potentially be converted to `Name`s in the same way as HIR to clearly separate identifiers used in hygienic and non-hygienic contexts.

r? @nrc
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
Improve `expl_impl_clone_on_copy`

fixes: rust-lang#1254

changelog: Check to see if the generic constraints are the same as if using derive for `expl_impl_clone_on_copy`
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 3, 2021
…giraffate

Update docs for `expl_impl_clone_on_copy`

The known issue was fixed in rust-lang#6993. I missed updating the docs then, so it's happening now.

changelog: None
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-syntaxext Area: Syntax extensions C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

Successfully merging a pull request may close this issue.