Uh oh!
There was an error while loading. Please reload this page.
Resolve $crates for pretty-printing at more appropriate time - #57155
Conversation
dtolnay
commented
Dec 27, 2018
@bors r+ |
bors
commented
Dec 27, 2018
📌 Commit e40d7d9 has been approved by |
bors
commented
Dec 28, 2018
Resolve `$crate`s for pretty-printing at more appropriate time Doing it in `BuildReducedGraphVisitor` wasn't a good idea, identifiers wasn't actually visited half of the time. As a result some `$crate`s weren't resolved and were therefore pretty-printed as `$crate` literally, which turns into two tokens during re-parsing of the pretty-printed text. Now we are visiting and resolving `$crate` identifiers in an item right before sending that item to a proc macro attribute or derive. Fixes#57089
bors
commented
Dec 28, 2018
☀️ Test successful - status-appveyor, status-travis |
@petrochenkov@dtolnay I noticed an issue with macro expansion with The issue started somewhere between nightlies I have an example here: https://gist.github.com/grovesNL/5d3ddc7b95c1939be26c64ba09f1ac2f (Original issue was reported in mozilla/cbindgen#272) |
grovesNL
commented
Jan 19, 2019
It's not clear if there is a better alternative at the moment – it's definitely very useful to have the expanded macro source for use cases like cbindgen. I guess cbindgen could special case certain "known" macros in cbindgen (i.e. bitflags and others) or the downstream crates using cbindgen could manually expand macros. Both of these options are a bit problematic, because it would mean cbindgen is unable to work with most macros in general. |
petrochenkov
commented
Jan 19, 2019
Ok, I'll try to fix this specific case since it worked before. |
grovesNL
commented
Jan 20, 2019
Thanks! Please note I also don’t mean to request a fix here if this use case isn’t supported, because it would inevitably break again at some point. I’m just trying to understand how we should go about making this work, even if it means reworking cbindgen heavily. #43364 discusses a long term fix a bit, but there doesn’t seem to be clear consensus yet. |
petrochenkov
commented
Jan 26, 2019
Fixed in #57915 |
Pretty print `$crate` as `crate` or `crate_name` in more cases So, people do parse output of `--pretty=expanded` (sigh), so covering only the legacy proc-macro case (like it was done in rust-lang#57155) is not enough. This PRs resolves all `$crate`s produced by macros, so they are all printed in the parseable form `$crate::foo` -> `crate::foo` or `crate_name::foo`. Fixesrust-lang#38016 (comment)Fixesrust-lang#57155 (comment)
Pretty print `$crate` as `crate` or `crate_name` in more cases So, people do parse output of `--pretty=expanded` (sigh), so covering only the legacy proc-macro case (like it was done in rust-lang#57155) is not enough. This PRs resolves all `$crate`s produced by macros, so they are all printed in the parseable form `$crate::foo` -> `crate::foo` or `crate_name::foo`. Fixesrust-lang#38016 (comment)Fixesrust-lang#57155 (comment)
…ulacrum Fix pretty-printing of `$crate` (take 4) Pretty-print `$crate` as `crate` or `crate_name` in unstructured tokens like `a $crate c` in `foo!(a $crate c)`, but only if those tokens are printed as a part of AST pretty-printing, rather than as a standalone token stream. Fixesrust-lang#62325 Previous iterations - rust-lang#56647, rust-lang#57155, rust-lang#57915.
Doing it in
BuildReducedGraphVisitorwasn't a good idea, identifiers wasn't actually visited half of the time.As a result some
$crates weren't resolved and were therefore pretty-printed as$crateliterally, which turns into two tokens during re-parsing of the pretty-printed text.Now we are visiting and resolving
$crateidentifiers in an item right before sending that item to a proc macro attribute or derive.Fixes#57089