The code is a hack. That is the best way of putting it, but it works.

I did think of maybe re-writing how WriteMode works as it seems, to me at lest, that not all the features are implemented/documented. That or I might have understood all of it, I'm pretty new at Rust.

It's now possible to create a file relative to a project that will override the default values. That file is called "rustfmt.toml". The default values are stored in a file called "default.toml" and are expected to be in the same folder as the binary, regardless of where the binary is stored.

A "default.toml" is still written next to the manifest because the test suite needs it.

Problem cargo fmt --all runs unexpectedly slow in a medium-sized workspace project.

Steps

1. Run a GitHub workflow that runs cargo fmt --all on the repository.
2. Check execution time.

This run shows rustfmt and/or cargo pausing for more than 20 s before producing any output in verbose mode. Seen with timestamps in the raw log:

2020-06-08T17:05:32.3268959Z [command]/usr/share/rust/.cargo/bin/cargo fmt --all --verbose -- --check --verbose
2020-06-08T17:05:55.8733086Z [bench (2018)] "/home/runner/work/chain-libs/chain-libs/btree/benches/benchmark.rs"

Notes

Output of cargo version: cargo 1.44.0 (05d080faa 2020-05-06)

Output of rustfmt --version rustfmt 1.4.14-stable (e417356 2020-04-21)

Virtual environment information from GitHub workflow: Operating System Ubuntu 18.04.4 LTS Virtual Environment Environment: ubuntu-18.04 Version: 20200518.1 Included Software: https://github.com/actions/virtual-environments/blob/ubuntu18/20200518.1/images/linux/Ubuntu1804-README.md

I have rustfmt-preview installed on the nightly toolchain (rustc 1.30.0-nightly (3edb355b7 2018-08-03)) using rustup.

Runningcargo +nightly fmt on the crate: https://github.com/frankmcsherry/differential-dataflow results in numerous "left behind trailing whitespace" errors. Some sample errors:

internal error: left behind trailing whitespace
  --> [..]/differential-dataflow/src/algorithms/prefix_sum.rs:70
   |
70 |         .iterate(|ranges| 
   |                          ^
warning: rustfmt may have failed to format. See previous 1 errors.

  --> [..]/differential-dataflow/examples/seb.rs:37
   |
37 |       let cooccurrences = 
   |                          ^
  --> [..]/differential-dataflow/examples/seb.rs:44
   |
44 |       let row_sums = 
   |                     ^

  --> [..]/differential-dataflow/examples/dataflow.rs:35
   |
35 |             let (tweet_input, tweets) = scope.new_collection(); 
   |                                                                ^

This error message doesn't tell me what are the consequences, and what can I do to avoid the problem.

Does "Rustfmt failed" mean the file could not be parsed and has not been formatted at all, or did it just skip that one line?

Is that a bug/limitation of rustfmt, or a lint telling me to format code better?

What's the maximum length? Can I configure it?

I've got these errors pointing to a few lines that only contain comments, and are 100-109 characters long. I'm confused, because it doesn't seem like an excessive line length that could cause a tool to fail.

Currently rustfmt formats from

            let mut arms = variants.iter().enumerate().map(|(i, &(ident, v_span, ref summary))| {
                let i_expr = cx.expr_usize(v_span, i);
                let pat = cx.pat_lit(v_span, i_expr);

                let path = cx.path(v_span, vec![substr.type_ident, ident]);
                let thing = rand_thing(cx, v_span, path, summary, |cx, sp| rand_call(cx, sp));
                cx.arm(v_span, vec!( pat ), thing)
            }).collect::<Vec<ast::Arm> >();

to

            let mut arms = variants.iter()
                                   .enumerate()
                                   .map(|(i, &(ident, v_span, ref summary))| {
                                       let i_expr = cx.expr_usize(v_span, i);
                                       let pat = cx.pat_lit(v_span, i_expr);

                                       let path = cx.path(v_span, vec![substr.type_ident, ident]);
                                       let thing = rand_thing(cx,
                                                              v_span,
                                                              path,
                                                              summary,
                                                              |cx, sp| rand_call(cx, sp));
                                       cx.arm(v_span, vec!(pat), thing)
                                   })
                                   .collect::<Vec<ast::Arm>>();

which is much worse than the original.

fix #4476 fix #4867 fix #5128

The problem in those issues is, when max_width is tight, rustfmt should check all possible formattings, which is exponential relative to input size. By memoization of format_expr function, worst case execution time becomes O(n*max_width^3). I tried codes in those issues and it completed in a fraction of second.

Fix for issue #3943. The root cause of the issue is that ::Foo from use ::Foo is represented by UseSegment::List as one item vector [::Foo]. However, in case of use ::{Foo}, after removing the {} the representation was two items vector [, Foo]. That caused the wrong sorting, as, for example cmp() considers [, Foo] as greater then [::foo]

The fix assumes that the one item vector [::Foo] is the right representation.

This option adds very little code, so it would be great to have it supported.

It's an enum, because the tracking issue originally asked for a space before generics too, which is not part of this PR. This option can be extended later to add BeforeGenerics or AroundGenerics as other values. https://github.com/rust-lang/rustfmt/pull/4302#discussion_r448549821

Tracking issue: #3564

Hello, it would be nice to have the option to put whitespace on empty lines to match the current indent level.

fn foo() {
   let thing = 1;
   <- Keep this indent.
   let thing = 2;
}

This one does not affect how the code is formatted but allows specific files or directories to be excluded from formatting.

What is needed for stabilizing this for one of the next releases?

This commit hides the about section when the search bar is not empty, making it more discoverable to users that search is indeed working and they should look in the options section.

Hi, it would be really cool if an attribute's content could be arranged in more ways. (Similar to array_width)

Example:

Currently, if you have this attribute:

#[diagnostic(
    code(...),
    url(...),
    severity(...)
)]
fn x() {...}

It will get rearranged to:

#[diagnostic(code(...), url(...), severity(...))]
fn x() {...}

It would be useful if there was an option specifically for vertical formatting in attributes' content

Minimal reproducer:

mod ok {
    mod ok {
        const _: &'static str = stringify!(Foo: !Bar);
    }
}

macro_rules! ok_2 {
    () => {
        const _: i32 = !1;
    };
}
ok_2!();

macro_rules! fail_dedented {
    () => {
        const _: &'static str = stringify!(Foo: !Bar);
    };
}
fail_dedented!();

macro_rules! fail_dedented_nonidempotent {
    () => {
        const _: () = assert!(stringify!(Foo: !Bar).len() > 0, concat!(stringify!(Foo: !Bar), "Lorem ipsum dolor sit amet, consectetur adipiscing elit"));
    };
}
fail_dedented_nonidempotent!();

macro_rules! fail_dedented_nonidempotent_2 {
    () => {
        const _: () = assert!(stringify!(Foo: !Bar).len() > 0, concat!(stringify!(Foo: !Bar), "Lorem ipsum dolor sit amet, consectetur adipiscing elit"));
    };
}

fail_dedented_nonidempotent_2!();

formats to

mod ok {
    mod ok {
        const _: &'static str = stringify!(Foo: !Bar);
    }
}

macro_rules! ok_2 {
    () => {
        const _: i32 = !1;
    };
}
ok_2!();

macro_rules! fail_dedented {
    () => {
const _: &'static str = stringify!(Foo: !Bar);
    };
}
fail_dedented!();

macro_rules! fail_dedented_nonidempotent {
    () => {
const _: () = assert!(
            stringify!(Foo: !Bar).len() > 0,
            concat!(
                stringify!(Foo: !Bar),
                "Lorem ipsum dolor sit amet, consectetur adipiscing elit"
            )
        );
    };
}
fail_dedented_nonidempotent!();

macro_rules! fail_dedented_nonidempotent_2 {
    () => {
const _: () = assert!(
            stringify!(Foo: !Bar).len() > 0,
            concat!(
                stringify!(Foo: !Bar),
                "Lorem ipsum dolor sit amet, consectetur adipiscing elit"
            )
        );
    };
}

fail_dedented_nonidempotent_2!();

formats to

mod ok {
    mod ok {
        const _: &'static str = stringify!(Foo: !Bar);
    }
}

macro_rules! ok_2 {
    () => {
        const _: i32 = !1;
    };
}
ok_2!();

macro_rules! fail_dedented {
    () => {
const _: &'static str = stringify!(Foo: !Bar);
    };
}
fail_dedented!();

macro_rules! fail_dedented_nonidempotent {
    () => {
        const _: () = assert!(
    stringify!(Foo: !Bar).len() > 0,
            concat!(
        stringify!(Foo: !Bar),
                "Lorem ipsum dolor sit amet, consectetur adipiscing elit"
            )
        );
    };
}
fail_dedented_nonidempotent!();

macro_rules! fail_dedented_nonidempotent_2 {
    () => {
        const _: () = assert!(
    stringify!(Foo: !Bar).len() > 0,
            concat!(
        stringify!(Foo: !Bar),
                "Lorem ipsum dolor sit amet, consectetur adipiscing elit"
            )
        );
    };
}

fail_dedented_nonidempotent_2!();

Fixes #5638

Block comments with bare lines are those that have lines without leading * characters. When reformatting these comments we should be mindful not to remove leading non-breaking spaces (U+00A0).

Fixes #5639

Now we'll preserve two blank lines at the end of block doc comments that contain bare lines (lines without a leading *).

For example, the newlines in the following block doc comment won't be removed.

/*!
This  
has  
breaks.
*/