[unstable option] imports_layout

[scampi]

Tracking issue for unstable option: imports_layout

[jimmycuadra]

What's necessary to stabilize this?

[scampi]

There are some steps described in https://github.com/rust-lang/rustfmt/blob/master/Processes.md#stabilising-an-option.
#3581 is an attempt at this.

[mzabaluev]

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).

[mzabaluev]

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.

[andreastt]

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.

[vn971]

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 🎉

[dtolnay]

I think "independent imports" (#3361 (comment)) is outside of what this option is for, and is a discussion for #3362 instead. It's already been brought up there in #3362 (comment).

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.

[Lokathor]

Shouldn't "mixed' be called "compressed" to match other similar options?

[Fishrock123]

Is this the same thing as imports_granularity? What kind of timeline / issues are there for stabilizing that?

[bartlomieju]

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).

[9999years]

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]

Is there anything missing to stabilize this option?

[9999years]

@Progdrasil One of the big things missing is dealing with comments in imports; see #4991 (comment)

[ytmimi]

linking #3286

[blyxyas]

The option LimitedHorizontalVertical isn't documented

[ytmimi]

@blyxyas PRs for doc improvements are always welcome 😁

[blyxyas]

I haven't made a PR because I don't know what it does
Sorry

[ytmimi]

@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.

rustfmt/src/config/mod.rs

Line 90 in 38659ec

imports_layout: ListTactic, ListTactic::Mixed, false, "Item layout inside a import block";

rustfmt/src/config/lists.rs

Lines 26 to 41 in 38659ec

	/// Formatting tactic for lists. This will be cast down to a
	/// `DefinitiveListTactic` depending on the number and length of the items and
	/// their comments.
	#[config_type]
	pub enum ListTactic {
	/// One item per row.
	Vertical,
	/// All items on one row.
	Horizontal,
	/// Try Horizontal layout, if that fails then vertical.
	HorizontalVertical,
	/// HorizontalVertical with a soft limit of n characters.
	LimitedHorizontalVertical(usize),
	/// Pack as many items as possible per row over (possibly) many rows.
	Mixed,
	}

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.

[tgross35]

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.

[ytmimi]

@tgross35 I believe the current formatting is correct based on the Nested import rules defined in the style guide

[tgross35]

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

[ytmimi]

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."

[tgross35]

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)

[daniel-wong-dfinity-org]

Can we make this stable as-is? Otherwise, it seems like perfect is being made the enemy of good.

[calebcartwright]

Can we make this stable as-is?

No.

Otherwise, it seems like perfect is being made the enemy of good.

That's not the case at all. There's a well documented set of criteria that our config options have to meet before they can be stabilized, not to mention that the Rust ecosystem takes the notion of stability pretty seriously. We don't stabilize something that has known bugs and known issues in interactions with other parts of the ecosystem (in this case other Rustfmt options)

#5365

[daniel-wong-dfinity-org]

There are people who cannot use this even though it would provide value.