* Add rough draft of `check` mode. Not unit tested.
* Added assert-cli; simple test case for `--write-mode=check`
* Lightly documented `check` WriteMode
* wrote clearer phrasing for config::options::WriteMode::Check
* Implemented default for WriteMode where default is Overwrite
* Simplified exit code handling
* updated README.md as per @nrc' comment
* collapsed exit-code handling
* Removed write_mode from Summary, introduced partial option parsing earlier
* Handle write-mode parsing in a slightly better way.
This commit suppresses the output of unstable config options by default.
Users can specify the `--unstable-features` option to show the config options
that are unstable.
Fixes#2611.
And improve docs, the error message, etc.
I think false is the better default since such errors should only occur due to a bug in Rustfmt and therefore most users should not be notified of it happening (although to be clear, it might be a 'bug' which only occurs with pathological input and therefore we won't fix it). The error has proven to be confusing and annoying in the past.
Closes#1080
For example, with the following config file, rustfmt will ignore `src/types.rs`,
`src/foo/bar.rs` and every file under `examples/` directory.
```toml
[ignore]
files = [
"src/types.rs",
"src/foo/bar.rs",
]
directories = [
"examples",
]
```
I'm not quite sure how best to handle loading the license template from
a path -- I mean obviously I know *how* to do it, but I'm not sure where
to fit it in the codebase :) So this first attempt puts the license
template directly into the config file.
These are my misgivings about the license template config option as a
path to a file (I'd love feedback if some of these are wrong or can be
easily circumvented!):
1. I thought the obvious choice for the type of `license_template` in
`create_config!` should be `PathBuf`, but `PathBuf` doesn't implement
`FromStr` (yet? see https://github.com/rust-lang/rust/issues/44431), so
it would have to be wrapped in a tuple struct, and I went down that road
for a little while but then it seemed like too much ceremony for too
little gain.
2. So a plain `String` then (which, mind you, also means the same
`doc_hint()`, i.e. `<string>`, not `<path>` or something like that). The
fact that it's a valid path will be checked once we try to read the
file.
3. But where in the code should the license template be read? The
obvious choice for me would be somewhere in `Config::from_toml()`, but
since `Config` is defined via the `create_config!` macro, that would
mean tight coupling between the macro invocation (which defines the
configuration option `license_template`) and its definition (which would
rely on the existence of that option to run the template loading code).
4. `license_template` could also be made a special option which is
hardwired into the macro. This gets rid of the tight coupling, but
special-casing one of the config options would make the code harder to
navigate.
5. Instead, the macro could maybe be rewritten to allow for config
options that load additional resources from files when the config is
being parsed, but that's beyond my skill level I'm afraid (and probably
overengineering the problem if it's only ever going to be used for this
one option).
6. Finally, the file can be loaded at some later point in time, e.g. in
`format_lines()`, right before `check_license()` is called. But to
face a potential *IO* error at so late a stage, when the source files
have already been parsed... I don't know, it doesn't feel right.
BTW I don't like that I'm actually parsing the license template as late
as inside `check_license()` either, but for much the same reasons, I
don't know where else to put it. If the `Config` were hand-rolled
instead of a macro, I'd just define a custom `license_template` option
and load and parse the template in the `Config`'s init. But the way
things are, I'm a bit at a loss.
However, if someone more familiar with the project would kindly provide
a few hints as to how the path approach can be done in a way that is as
clean as possible in the context of the codebase, I'll be more than
happy to implement it! :)
