-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Eliminate $crate in --pretty=expanded #38016
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: