Skip to content

Add support for moving module imports into the same use statement as their children (with self) #4915

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
zedseven opened this issue Jul 22, 2021 · 2 comments

Comments

@zedseven
Copy link

When importing things, my IDE isn't very smart about how it adds new use statements. Thankfully rustfmt mostly cleans it up, but one thing it doesn't seem to do is move module imports into the same block as their children if some of their components are also imported.

A common case for me is when manually implementing Debug on something - I often end up with the following after rustfmt cleans up (with imports_granularity = "Crate"):

use std::{
	fmt,
	fmt::{Debug, Formatter},
};

...

impl Debug for MyStruct {
	fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
		f.debug_struct("MyStruct")
			...
			.finish()
	}
}

It would be nice to have an option (or default behaviour, I'm not sure) to have rustfmt format the imports as:

use std::fmt::{self, Debug, Formatter};

...

It saves space, looks cleaner, and in a big import tree, makes it easier to read imo.

@calebcartwright
Copy link
Member

Thanks for reaching out, but I suspect this would run into the same non-semantics preserving behavior as described in rust-lang/rust#60941 and is not something rustfmt would be able to do.

If you're confident that can be guaranteed to always preserve semantics then please let us know and we'll reconsider!

@zedseven
Copy link
Author

Ah, I wasn't aware of that subtlety. You're right, it doesn't look possible for the moment.
Thanks for your reply!

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

2 participants