-
Notifications
You must be signed in to change notification settings - Fork 889
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
group_imports
does not differentiate between a local import and an external crate
#4709
Comments
@rustbot modify labels to +a-imports +only-with-option |
Error: This repository is not enabled to use triagebot. Please let |
Also, |
Hm, when we added this feature I thought there was no good way to differentiate between external and local imports if the latter were not explicitly prefixed, but taking a look at the code again, we might be able to use the (recently added?) file_mod_map field in the context. I'll experiment with this today.
Good point. Is there a list of standard crates somewhere? It would be nice to make sure we're not missing any others. |
Removing the bug label, as there's definitely not one here though perhaps some minor updates to the documentation for the variant could be helpful to explain the limitations. As discussed in various other issues/pulls, including the recent #4693, I'm still highly skeptical that it will be possible to do more. Would be thrilled to be proven wrong as I know folks would appreciate these types of enhancements from rustfmt, but to reiterate a few points:
|
Of course the definition of "local" is up for debate, but under the definition currently used, wouldn't it be possible to just see if there is a |
Also found that we had some files in |
This enables the `group_imports` option. With this rustfmt automatically groups the imports in `std`, `external`, and `crate. This is almost what we already wanted but we lose control of some things: * it is not able to differentiate between workspace and external so all our crates will go in that section, * it does not understand local import: ```rust mod foo { struct Foo; } use foo::Foo; use rand::random; ``` instead of having a separate group for `foo`. * It does not respect groups that we create manually ```rust use tokio; use itertools; ``` the imports will be merged. Looking at the changeset we are not too bad at maintaining this style. Most of the changes are the position of `crate` wr.t. to `self` or `super`, fusing groups, and moving our workspace crates to the external one. But this will be our only option to enforce this style with a tool. https://rust-lang.github.io/rustfmt/?version=v1.5.1&search=#group_imports rust-lang/rustfmt#4709 rust-lang/rustfmt#4693
In that case the docs should be updated. The docs say "external crates" go into the middle group, and in the example in the OP, It seems like the middle group are "external crates as well as local modules that are not prefixed with |
I have drafted an implementation of a lint that could be used to enforce all local imports to be recognizable by rustfmt: rust-lang/rust#125645. |
…ethercote add unqualified_local_imports lint This lint helps deal with rust-lang/rustfmt#4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
add unqualified_local_imports lint This lint helps deal with rust-lang/rustfmt#4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
Describe the bug
rustfmt
does not differentiate between local imports not prefixed byself::
and external crates. The behavior is as expected when prefixed byself::
.To Reproduce
Using
group_imports = "StdExternalCrate"
inrustfmt.toml
, the following code is considered formatted.Expected behavior
rustfmt
recognizes thatfoo
is a local module, not an external crate.Meta
cargo fmt
The text was updated successfully, but these errors were encountered: