Skip to content
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

Opinionated sorting of use statement blocks #4107

Closed
projektir opened this issue Apr 2, 2020 · 2 comments · Fixed by #4445
Closed

Opinionated sorting of use statement blocks #4107

projektir opened this issue Apr 2, 2020 · 2 comments · Fixed by #4445

Comments

@projektir
Copy link

So currently rustfmt appears to only sort use statements that are next to each other, but often in our projects we like to neatly organize the use statements into blocks and sort them according to some scheme. Usually, something like this:

use std::sync::Arc;

use chrono::Utc;
use juniper::{FieldError, FieldResult};
use uuid::Uuid;

use broker::database::PooledConnection;

use super::schema::{Context, Payload};
use super::update::convert_publish_payload;
use crate::models::Event;

So the order here is:

  • std (core, alloc would also fit here)
  • external crates
  • workspace crates (I assume this is not something rustfmt can identify, sadly)
  • this module.

It would be awesome to have both the sorting within the blocks like rustfmt already currently does and sorting of the categories between the blocks. So, say, a soup like this:

use chrono::Utc;
use super::update::convert_publish_payload;

use juniper::{FieldError, FieldResult};
use uuid::Uuid;
use std::sync::Arc;

use broker::database::PooledConnection;

use super::schema::{Context, Payload};
use crate::models::Event;

Would reformat into the neat code block above. Of course, this could be optional / configurable.

I.e., not having to worry about use ordering ever again... 😄

@calebcartwright
Copy link
Member

While this should be possible to implement, there is an existing challenge/class of bugs rustfmt has with maintaining inline comment association while reordering imports.

It may not be strictly necessary to address that comment-import association before implementing this, but would be good to do so if possible because those existing comment issues would definitely be exacerbated by rustfmt reordering entire import blocks.

@calebcartwright
Copy link
Member

Actually we've got some duplication here with #4070

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