-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Minor refactorings & implement --pretty expanded,hygiene to see syntax context & gensym information #16419
Conversation
This isn't as informative as it could be (#16420), but the gensym information is useful and the syntax context stuff is still useful as a basic positive test (i.e. if two identifiers with the same name also have the same syntax context, then they're the same). |
(I will review) |
@huonw so while I regard this as a net-win (and thus I r-plused it), I idly wonder: What is more important for a person using this -- that the names correspond to the names that would be printed via things like fn bar_61_0 /* 61#0 */() { y /* 60#2 */ + x /* 58#3 */ } as this instead: #![feature(non_ascii_idents)]
fn barʃ61ʃ0() { yʃ60ʃ2 + xʃ58ʃ3 } (where I have chosen to put a non-ascii character as the marker for where the meta-data starts to reduce the chance that it will end up actually colliding with an actual variable from the source text -- another, more robust option would be to dynamically choose between |
Ah, that's an interesting point. I hadn't thought of it, and it does seem like it could be better than just comments. (On that note, if we want pretty printing to always compile & not change semantics, then |
Nonetheless we can adopt this PR for now and put my suggestion down as a back burner task |
There's a lot of it, and it's a fairly well-defined/separate chunk of code, so it might as well be separate.
The type in the `impl` is now in the module with the trait.
ec2680b
to
7d7d907
Compare
7d7d907
to
1e45d84
Compare
1e45d84
to
d79047e
Compare
`--pretty expanded,hygiene` is helpful with debugging macro issues, since two identifiers/names can be textually the same, but different internally (resulting in weird "undefined variable" errors).
d79047e
to
32e4371
Compare
Different Identifiers and Names can have identical textual representations, but different internal representations, due to the macro hygiene machinery (syntax contexts and gensyms). This provides a way to see these internals by compiling with `--pretty expanded,hygiene`. This is useful for debugging & hacking on macros (e.g. diagnosing #15750 likely would've been faster with this functionality). E.g. ```rust #![feature(macro_rules)] // minimal junk #![no_std] macro_rules! foo { ($x: ident) => { y + $x } } fn bar() { foo!(x) } ``` ```rust #![feature(macro_rules)] // minimal junk #![no_std] fn bar /* 61#0 */() { y /* 60#2 */ + x /* 58#3 */ } ```
Add missing unpretty option help message There are some missing help messages that is printed `ructc -Zunpretty help` and receiving invalid option. related with rust-lang#16419, rust-lang#45721, rust-lang#21085, rust-lang#31916
Add missing unpretty option help message There are some missing help messages that is printed `ructc -Zunpretty help` and receiving invalid option. related with rust-lang#16419, rust-lang#45721, rust-lang#21085, rust-lang#31916
Different Identifiers and Names can have identical textual representations, but different internal representations, due to the macro hygiene machinery (syntax contexts and gensyms). This provides a way to see these internals by compiling with
--pretty expanded,hygiene
.This is useful for debugging & hacking on macros (e.g. diagnosing #15750 likely would've been faster with this functionality).
E.g.