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.
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?
