Open wmmc88 opened 2 months ago
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
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.
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
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.
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 ofcargo 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)
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).
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 https://github.com/rust-lang/rust/issues/105336 + https://github.com/rust-lang/rfcs/pull/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'm not entirely sure what you're asking, but I'm guessing RFC 3338 (and https://github.com/rust-lang/rust/issues/105336 + https://github.com/rust-lang/rfcs/pull/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.
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 personalrustfmt.toml
. I would like an option in therustfmt
cli to prevent recursively searching for arustfmt.toml
file.