Skip to content

Rustfmt changes meaning of 2018 import starting with colons #3501

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

Closed
dtolnay opened this issue Apr 9, 2019 · 5 comments
Closed

Rustfmt changes meaning of 2018 import starting with colons #3501

dtolnay opened this issue Apr 9, 2019 · 5 comments

Comments

@dtolnay
Copy link
Member

dtolnay commented Apr 9, 2019

Repro against current master branch (8ec0750):

echo 'use ::serde::Serialize; mod serde {}' | cargo run --bin rustfmt

Output:

use serde::Serialize;
mod serde {}

The original code imports ::serde::Serialize which refers to the external crate serde, not the local module. The formatted code imports serde::Serialize which refers to the local module and does not exist.

Interestingly, cargo fmt against the same code does not break the code, presumably because cargo fmt somehow understands that the edition of this code is 2018 and so the leading :: is meaningful. In the absence of knowing the edition for sure, would it be possible for rustfmt to treat this case more conservatively and keep the leading ::? We can continue to remove the colons if the edition is known to be 2015.

@scampi
Copy link
Contributor

scampi commented Apr 9, 2019

If you put edition = "2018" in the config file that should be fine

@scampi
Copy link
Contributor

scampi commented Apr 9, 2019

cargo fmt picks up the edition from Cargo.toml

@topecongiro
Copy link
Contributor

If you are running rustfmt directly you need to pass --edition flag to rustfmt: cargo run --bin rustfmt -- --edition 2018. As the default edition of rustc and cargo are both 2018, I think it's reasonable to change the default edition of rustfmt to 2018 in 2.0.

@dtolnay
Copy link
Member Author

dtolnay commented Apr 17, 2019

Thanks, I think this is user error and I should be passing --edition 2018.

I don't know if this is helpful but I filed #3517 to track bumping the default edition that is assumed when no --edition is passed.

@dtolnay dtolnay closed this as completed Apr 17, 2019
@topecongiro
Copy link
Contributor

@dtolnay That is indeed helpful, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants