rustfmt
rustfmt copied to clipboard
rust-lang
[unstable option] imports_layout
There are some steps described in https://github.com/rust-lang/rustfmt/blob/master/Processes.md#stabilising-an-option. https://github.com/rust-lang/rustfmt/pull/3581 is an attempt at this.
Why does Horizontal have to exceed max_width?
How does this behavior interact with merge_imports = true?
I think it should be possible to try to fit all import statements into max_width, replicating the path prefix for any spill-over items into the next line(s).
One good reason to prefer the Horizontal layout (and stabilize this setting after the behavioral aspects are ironed out) is to keep the imports searchable with grep-like tools that don't easily match across multiple lines.
A counter-argument for Vertical sorting is that it makes rebases significantly easier.
I recently had to do a rebase of a fairly complicated refactoring that moved lots of types around, and git rebase tools for in-line changes is not great.
I would like to use this feature in mozilla-central once it’s stablised.
I would love independent imports:
use foo::{
aaaaaaaaaaaaaaaaaa, bbbbbbbbbbbbbbbbbb, cccccccccccccccccc, dddddddddddddddddd,
eeeeeeeeeeeeeeeeee, ffffffffffffffffff,
};
=>
use foo::aaaaaaaaaaaaaaaaaa;
use foo::bbbbbbbbbbbbbbbbbb;
use foo::cccccccccccccccccc;
use foo::dddddddddddddddddd;
use foo::eeeeeeeeeeeeeeeeee;
use foo::ffffffffffffffffff;
As a possible alternative, I find this style super-friendly to git, immediately readable to my tastes, easy to play around with commenting-uncommenting.
Is it possible to have it as an ~~independent~~ alternative option?
UPDATE: this has been implemented in the (currently unstable) option imports_granularity :tada:
I think "independent imports" (https://github.com/rust-lang/rustfmt/issues/3361#issuecomment-632661079) is outside of what this option is for, and is a discussion for https://github.com/rust-lang/rustfmt/issues/3362 instead. It's already been brought up there in https://github.com/rust-lang/rustfmt/issues/3362#issuecomment-641125438.
AIUI the two options are orthogonal and the distinction is as follows: you can think of merge_imports as determining the tokens of our imports i.e. how/whether they should be grouped i.e. which parts of which specific paths should go inside of the same curly braces; while imports_layout determines the whitespace of each import after the point that the tokens have already been decided.
To explain for new people reading this issue. imports_layout is not going to be stabilized and is instead replaced with imports_granularity #3362 (comment)
This is incorrect. merge_imports was superseded by imports_granularity, there was no impact and no change to imports_layout which was a different option that controlled different formatting aspects.
Is this the same thing as imports_granularity? What kind of timeline / issues are there for stabilizing that?
Deno project is very interested in this setting as well (because we only use latests stable Rust toolchain).
We'd prefer to format to have a single import per line (which is is very git diff friendly).
Is this the same thing as
imports_granularity? What kind of timeline / issues are there for stabilizing that?
I've opened #4991 to track imports_granularity.
@Progdrasil One of the big things missing is dealing with comments in imports; see https://github.com/rust-lang/rustfmt/issues/4991#issuecomment-939537120
@blyxyas no worries. I also couldn't have told you what it did before looking into it. From what I can tell it's meant to let you control the width at which imports wrap from being laid out horizontally to being laid out vertically, however I don't think we support parsing config options that take a value, and that might be why its not documented.
imports_layout config option maps to the ListTactic enum.
https://github.com/rust-lang/rustfmt/blob/38659ec6ad5f341cf8eb3139725bf695872c6de7/src/config/mod.rs#L90
https://github.com/rust-lang/rustfmt/blob/38659ec6ad5f341cf8eb3139725bf695872c6de7/src/config/lists.rs#L26-L41
I tried setting it from the command line and got an error
rustfmt --config="imports_layout=LimitedHorizontalVertical"
invalid key=val pair: `imports_layout=LimitedHorizontalVertical`
rustfmt --config="imports_layout=LimitedHorizontalVertical(50)"
invalid key=val pair: `imports_layout=LimitedHorizontalVertical(50)`
The ListTactic enum is pretty general and is used internally to format many different types of lists. Maybe it makes more sense to create a new ImportsListTactic enum that exposes the same options as ListTactic except the LimitedHorizontalVertical(50) variant. Given that LimitedHorizontalVertical(_) can't be set (at least not from the command line) maybe it's not worth it to make that change.
It seems like there are some weird interactions with the imports_granularity option. For example, with import_granularity = "Crate" and imports_layout = "Horizontal":
use foo::{
a, b, b::{f, g}, c, d::e
};
use qux::{h, i};
HorizontalVertical
use foo::{
a,
b,
b::{f, g},
c,
d::e,
};
use qux::{h, i};
Mixed (default)
use foo::{
a, b,
b::{f, g},
c,
d::e,
};
use qux::{h, i};
None of those really match up with what I would expect based on the examples, it seems like it jumps to multiline too quick.
@tgross35 I believe the current formatting is correct based on the Nested import rules defined in the style guide
If there are any nested imports in a list import, then use the multi-line form, even if the import fits on one line. Each nested import must be on its own line, but non-nested imports must be grouped on as few lines as possible.
I guess that does line up. Though I'm not sure why "Horizontal" breaks into a multiline group when it's not close to line length
Though I'm not sure why "Horizontal" breaks into a multiline group when it's not close to line length
@tgross35 From the style guide: "If there are any nested imports in a list import, then use the multi-line form, even if the import fits on one line."
It was just my initial understanding that Horizontal breaks the rules to keep everything on one line, e.g., in the docs it says that it may exceed line length. There just isn't an example with nested modules in the docs. (fwiw, I don't have any problem with the behavior, it just didn't line up with my impression from the docs)