Description
Similar to #37637 so cc @jseyfried.
cat src/main.rs
fn main() { println!("rust"); }
rustc --pretty=expanded -Zunstable-options src/main.rs
#![feature(prelude_import)] #![no_std] #[prelude_import] use std::prelude::v1::*; #[macro_use] extern crate std as std; fn main() { $crate::io::_print(::std::fmt::Arguments::new_v1({ static __STATIC_FMTSTR: &'static [&'static str] = &["rust\n"]; __STATIC_FMTSTR }, &match () { () => [], }));
The $crate
prevents the expanded code from being parsed by rustfmt.
rustc --pretty=expanded -Zunstable-options src/main.rs | rustfmt
error: expected expression, found `$` --> stdin:8:5 | 8 | $crate::io::_print(::std::fmt::Arguments::new_v1({ | ^
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.
Activity
nagisa commentedon Nov 26, 2016
Why are you relying on unstable features for, umm, stable tooling?
--pretty
et al by now are only used for debugging purposes and won’t be stabilised.bluss commentedon Nov 26, 2016
I don't think expand can produce valid Rust code (how does it handle hygiene?)
dtolnay commentedon Nov 26, 2016
Before the
$crate
change, it produced syntactically valid Rust code even if the semantics were different in the case of hygiene collisions. This was useful for debugging purposes as @nagisa points out.Since the
$crate
change, it produces syntactically invalid code which I consider a bug.jseyfried commentedon Dec 21, 2016
Fixed in #38232 (#38232 (comment)).
After that lands, we will pretty-print
$crate::io::_print
as::io::_print
.xiaoniu-578fa6bff964d005 commentedon Jan 20, 2019
$crate
shows up again!rustc +nightly-2018-06-13-x86_64-unknown-linux-gnu --pretty=expanded -Zunstable-options main.rs
rustc +nightly --pretty=expanded -Zunstable-options main.rs
rustc +nightly --version
petrochenkov commentedon Jan 20, 2019
Caused by #57155.
Reopening and assigning to myself.
11 remaining items