This is a copy of #4296 with these changes:
* file is not reopened again to find if the file is generated
* first five lines are scanned for `@generated` marker instead of one
* no attempt is made to only search for marker in comments
`@generated` marker is used by certain tools to understand that the
file is generated, so it should be treated differently than a file
written by a human:
* linters should not be invoked on these files,
* diffs in these files are less important,
* and these files should not be reformatted.
This PR proposes builtin support for `@generated` marker.
I have not found a standard for a generated file marker, but:
* Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated)
* Phabricator tool which was spawned from Facebook internal tool
[also understands `@generated` marker](https://git.io/JnVHa)
* Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP)
My personal story is that rust-protobuf project which I maintain
was broken twice because of incompatibilities/bugs in rustfmt marker
handling: [one](https://github.com/stepancheg/rust-protobuf/issues/493),
[two](https://github.com/stepancheg/rust-protobuf/issues/551).
(Also, rust-protobuf started generating `@generated` marker
[6 years ago](https://git.io/JnV5h)).
While rustfmt AST markers are useful to apply to a certain AST
elements, disable whole-file-at-once all-tools-at-once text level
marker might be easier to use and more reliable for generated code.
In the event a pattern starts with a leading pipe
the pattern span will contain, and begin with, the pipe.
This updates the process to see if a match arm contains
a leading pipe by leveraging this recent(ish) change to
the patterns in the AST, and avoids an indexing bug that
occurs when a pattern starts with a non-ascii char in the
old implementation.
This renames the existing `true`/`false` options to `Crate`/`Never`, then adds a
new `Module` option which causes imports to be grouped together by their
originating module.
We no longer flatten a block that looks like this:
```rust
match val {
pat => { macro_call!() }
}
```
Currently, rust ignores trailing semicolons in macro expansion in
expression position (see https://github.com/rust-lang/rust/issues/33953)
If this is changed, flattening a block with a macro call may break the
user's code - the trailing semicolon will no longer parse if the macro
call occurs immediately on the right-hand side of the match arm
(e.g. `pat => macro_call!()`)
When either one of these two options are set to `true`, each should take
precedence over the brace_style option.
This commit does not introduce any formatting change to the default
configuration, so no version gate is required.
If we're only aligning enum discriminants that are "not too far apart
(length-wise)", then this works really well for enums with
consistently-long or consistently-short idents, but not for the mixed
ones.
However, consistently-long idents is somewhate of an uncommon case and
overlong idents may be allowed to be formatted suboptimally if that
makes mixed-length idents work better (and it does in this case).
Add `reorder_modules` config option.
Two things we must keep in mind when reordering modules:
1. We should not reorder modules with attributes, as doing so could
potentially break the code (e.g. `#[macro_use]`).
2. We should not reorder inline modules e.g. `mod foo { /* .. */ }`.
We should only reorder module declarations e.g. `mod foo;`.
Some open questions:
1. Should we bring modules with `pub` in front of those without `pub`
so that they stand out from others?
2. Instead of keeping modules with attributes in the same place,
can we bring them in front of others? Is this safe?
