Open matthiaskrgr opened 6 years ago
It seems to me that in the latter case rustfmt is not using the expected rustfmt.toml. Could you please try without rustfmt.toml and see if those two still format differently?
cargo fmt --all
and cargo fmt --all -- --config-path ../rustfmt.toml
seem to behave identical
and
fd \.rs -x rustfmt
and fd \.rs -x rustfmt --config-path ../rustfmt.toml ;
seem to behave identical
For the record, I also get the different formatting behavior between cargo fmt --all
and rustfmt <file>
after removing the rustfmt.toml
.
I tried to understand how cargo fmt
works.
It seems that rustfmt file1 file2 file3 file4
(the cargo fmt
strategy) behaves differently from
for i in `find . | grep "\.rs$"`; do
rustfmt $i
; done
When formatting clippy_lints
, it seems that rustfmt
throws a bad exit status on bit_mask.rs
(theres no output in -verbose
unfortunately).
I assume what happens is that when formatting everything at once, it fails formatting that file and then stops processing all other files afterwards.
I have the same issue using:
https://github.com/otavio/updatehub
It fails with 101 exit status. Running it on all files does format them but using cargo fmt --all
is failing badly.
I found that the option which, in our case, triggers the issue is the wrap_comments
[1] and dropping the documentation comments[2] "solve" the problem.
@otavio checking what's wrong with your example, looks like it is the code block.
@otavio checking what's wrong with your example, looks like it is the code block.
Do you mean the diagram?
yes
But why it would abort rustfmt? and more important ... silently?
I reported #3055 with a small test case for the issue.
I'd like to mention that as #3055 has been fixed, this does not happen to me anymore. However, this issue seems to be a general issue which rustfmt
may die, and just abort the formatting of the rest of files.
It would be good if it at least prints something on the stderr so the user knows it is stopping the formatting without completing.
This is a very old issue, but I started seeing this problem in tests folders (when using a lib.rs
) when the line ending is mixed-up.
I will investigate, but it basically fails silently.
EDIT: It seems to happen when you use very long strings
Is there a way around this yet? I have a very long and descriptive name like update_transaction_from_database_after_bla_bla
plus even more arguments to this function. I suspect this is what causing cargo fmt
to just bail out. Is there any reason why this even happen?
Can anyone provide a link to a repo where this still happens?
meta:
rustc 1.30.0-nightly (2d4e34ca8 2018-09-09)
cargo fmt --version
:rustfmt 0.99.4-nightly (1c40881 2018-08-27)
rustfmt --version
:rustfmt 0.99.4-nightly (1c40881 2018-08-27)
example crate: clippy
changed files:
changed files:
What is going on here?