Skip to content

More advanced group_imports with 4 groups and adaptable "std-like" crates #5550

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

Open
DrSloth opened this issue Sep 30, 2022 · 1 comment · May be fixed by #5632
Open

More advanced group_imports with 4 groups and adaptable "std-like" crates #5550

DrSloth opened this issue Sep 30, 2022 · 1 comment · May be fixed by #5632

Comments

@DrSloth
Copy link

DrSloth commented Sep 30, 2022

In code i write i have taken to group the import statements into 4 groups:

  1. "std-like" crates which include all the normal std crates (std, alloc, core) and large crates like tokio or frameworks like axum or bevy pretty much everything which fundamentaly controls how my code will look like.
  2. Other external crates
  3. Workspace internal crates
  4. Crate internal imports

I have thought about trying to implement this in rustfmt, but i don't know how doable this is.
I guess making crates in 1. optionally configurable shouldn't be that hard, but does rustfmt get any workspace information? Is it feasible to optionally implement retrieving workspace information for such a feature, or would this require some larger architectural/conceptual change?

Thanks in advance :)

@ytmimi
Copy link
Contributor

ytmimi commented Sep 30, 2022

rustfmt only operates on the AST provided by the rustc parser and doesn't get any information that would help it determine the difference between local and external crates in a consistent way.

Some related issues: #4693, #4709, #4788

@l4l l4l linked a pull request Dec 10, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants