-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Eliminate $crate in --pretty=expanded #38016
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Why are you relying on unstable features for, umm, stable tooling? |
I don't think expand can produce valid Rust code (how does it handle hygiene?) |
Before the Since the |
Fixed in #38232 (#38232 (comment)). |
|
Caused by #57155. |
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`. Fixes rust-lang#38016 (comment) Fixes rust-lang#57155 (comment)
Similar to #37637 so cc @jseyfried.
cat src/main.rs
rustc --pretty=expanded -Zunstable-options src/main.rs
The
$crate
prevents the expanded code from being parsed by rustfmt.rustc --pretty=expanded -Zunstable-options src/main.rs | rustfmt
This breaks
cargo expand
which runs the code through rustfmt by default.I think
--pretty=expanded
should produce valid Rust code which means either eliminate$crate
like we did for #37637, or allow rustfmt to parse it.The text was updated successfully, but these errors were encountered: