Feature Request: Ignore `rustfmt.toml`

Question

Feature Request: Ignore `rustfmt.toml`

wmmc88 opened this issue 2 months ago · 8 comments

I have a rustfmt.toml that contains many unstable options that I use for some of my personal projects. When contributing to other people's open source projects who use the default rustfmt settings (i.e. dont have a rustfmt file committed), rustfmt will recursively search parents until it finds my personal rustfmt.toml. I would like an option in the rustfmt cli to prevent recursively searching for a rustfmt.toml file.

Answer 1 · 2024-08-04T13:21:48.000Z

As a workaround, you could always have a blank config file or a default config file on your system named something other than rustfmt.toml or .rustfmt.toml so that it won't conflict with your personal config file. Then when formatting these other projects you can use the --config-path CLI argument to specify the path to this default formatting file.

With an empty config file (implicit defaults)

touch empty.toml
rustfmt -v --config-path empty.toml example.rs

With the default config file (explicit defaults)

rustfmt --print-config default > path/to/file.toml 
rustfmt -v --config-path path/to/file.toml example.rs

I'm passing the -v flag in the examples above so that you can clearly see which config file is loaded. For example, you should see output like this:

Using rustfmt config file empty.toml
Formatting example.rs
Spent 0.000 secs in the parsing phase, and 0.000 secs in the formatting phase

Answer 2 · 2024-09-03T15:41:53.000Z

In rust-lang/cargo#14442, an empty config was proposed for Cargo to workaround one users rustfmt.toml. So far, Cargo team members have had different opinions on whether the fault is with Cargo and we need an empty config or the fault is with using a user-wide config.

Answer 3 · 2024-09-03T19:03:05.000Z

my initial reaction is that anyone that's using a global config file locally is going to run the risk of speciously applying their local/personal settings (which they likely have globally as a convenience when working on their own projects/projects who's settings they control), and that is a risk they volunteer for by creating the global file in the first place and then running formatting in overwrite mode.

i think that individual projects can choose to take action to guard against that on behalf of any/all users, but I don't think they are fault for not having taken that action,

that being said, the introduction of Style Editions and the continuance of the current paradigm of rustfmt and cargo fmt both being run regularly in different contexts is going to result in us strongly recommending projects have a rustfmt.toml file with the style_edition specified to avoid CI cargo fmt --checks from contradicting the local rustfmt changes, often triggered by editor format-on-save behavior

Answer 4 · 2024-09-03T19:38:42.000Z

that being said, the introduction of Style Editions and the continuance of the current paradigm of rustfmt and cargo fmt both being run regularly in different contexts is going to result in us strongly recommending projects have a rustfmt.toml file with the style_edition specified to avoid CI cargo fmt --checks from contradicting the local rustfmt changes, often triggered by editor format-on-save behavior

To be clear, this suggestion is primary so people can run rustfmt instead of cargo fmt and get the same result? At least for myself and my personal projects, I would lean towards not supporting that use case.

Answer 5 · 2024-09-03T20:03:07.000Z

that being said, the introduction of Style Editions and the continuance of the current paradigm of rustfmt and cargo fmt both being run regularly in different contexts is going to result in us strongly recommending projects have a rustfmt.toml file with the style_edition specified to avoid CI cargo fmt --checks from contradicting the local rustfmt changes, often triggered by editor format-on-save behavior

To be clear, this suggestion is primary so people can run rustfmt instead of cargo fmt and get the same result? At least for myself and my personal projects, I would lean towards not supporting that use case.

it's not just about people/personal preferences. as far as i know, all editor/ides that support "format on save" use the lower level rustfmt tool because they're just formatting a single file or even just a subset of the lines within a file. cargo fmt will pick up content from Cargo.toml, rustfmt will not

so post 2024, projects that decide to elide a rustfmt config file will functionally be deciding to require contributors that want format-on-save behavior to each have to do local ide/editor configuration

(edit: correction)

Answer 6 · 2024-09-03T20:15:20.000Z

Which issue is tracking that? I'm curious to see what options were discussed for the IDE use case (and don't want to take up this issue discussing it).

Answer 7 · 2024-09-03T22:04:15.000Z

Sorry I was rushing earlier and misspoke significantly (also corrected in prior comment).

Projects that choose to not include a rustfmt config file do push a bit of that burden onto contributors that want to utilize format-on-save features in editors/ides, and it's been that way since Rust released the 2018 edition.

That's because the Project-wide default on edition still being 2015, and editors/ides running rustfmt directly, where without rustfmt being explicitly told to use the 2018 or 2021 edition when attempting to parse code it'll crash rather loudly

So it's already been relatively common for developers to run into this and need to either adjust their editor's formatting configuration to explicitly include the edition, or to work with the project's maintainers to get the rustfmt config added to the project with the edition value.

The only notable difference with style edition from my perspective is that it's an issue most devs won't notice until they've pushed and triggered CI, as opposed to with edition which pops up in the inner dev-loop

Which issue is tracking that? I'm curious to see what options were discussed for the IDE use case

I'm not entirely sure what you're asking, but I'm guessing RFC 3338 (and rust-lang/rust#105336 + rust-lang/rfcs#3338 by extension) may have what you're looking for.

I'll add that it's very much intentional from a t-style and t-rustfmt pov to maintain the current 2015 by default behavior, and it's an implementation detail/decision outside our scope for how rustfmt is executed by editors/ides (though I understand their reasoning; you can't cargo fmt a single function in a single file, and there's very valid reasons why editor format-on-save would only want to format the code that was modified)

Answer 8 · 2024-09-03T23:55:41.000Z

I'm not entirely sure what you're asking, but I'm guessing RFC 3338 (and rust-lang/rust#105336 + rust-lang/rfcs#3338 by extension) may have what you're looking for.

I'll add that it's very much intentional from a t-style and t-rustfmt pov to maintain the current 2015 by default behavior, and it's an implementation detail/decision outside our scope for how rustfmt is executed by editors/ides (though I understand their reasoning; you can't cargo fmt a single function in a single file, and there's very valid reasons why editor format-on-save would only want to format the code that was modified)

I emphasized the key point. I understand the need for compatibility. I understand that rustfmt is agnostic of cargo like rustc is. What I'm looking for is any discussion on ways to improve the IDE experience so a rustfmt.toml is not required to be duplicating information from Cargo.toml for the sake of IDEs. For example, maybe cargo fmt could allow formatting a single file or a selection within a file.