rustfmt splits chain into multiline when the length of chain exceeds
`chain_one_line_max`. However, currenly this rule only applies when the chain
has more than one child. This can lead to unexpected long chain if the parent
is long. This commit adds heuristic that if the length of parent is longer
than the half of `chain_one_line_max` we use multiline even if there is
only a single child.
- `--dump-default-config` outputs the default configuration to the
specified file as TOML and then exits.
- `--dump-minimal-config` is checked after formatting files as normal.
If present, any configuration options that were checked during
formatting are written to the specified file as TOML.
- These options were added only to `rustfmt`, not to `cargo fmt`. They
can be specified when using `cargo fmt` by placing them after `--`.
- It would have been nice if the filename was optional, so you could
run just `rusfmt --dump-minimal-config build.rs` to have it output to
`rustfmt.toml`. However, this doesn't do what you might expect: it
outputs the config to `build.rs`!
Leave serialization to the caller, but provide a
`PartialConfig.to_toml()` method, to deal with the fact that
`file_lines` can't be serialized.
Add a simple test.
This API isn't fantastic, but it's the best I can come up with without
something like `concat_idents!()`. There are relatively few places where
config is set, to hopefully the ugliness isn't disastrous.
Change previous occurences of `config.item = value` to this new API,
rather than using `config.override_value()`. Undo the changes to
`override_value()`, as it's no longer important to propogate the error
to the caller. Add a test for the new interface.
Two different modes:
- Serialize the full Config object. This is useful as
`Config::default().to_toml()` to output a rustfmt.toml with defaults
(#317).
- Serialize only the options that have been accessed. This could be
useful to output a minimal rustfmt.toml for a project. (If the
default value of any unused config item changes, you'll then get the
new default when you come to use it).
This commit doesn't expose this anywhere - deciding a sensible CLI is a
bit trickier.
This commit also has very simple error reporting (Result<String,
String>) - once the CLI is decided, a more sensible method of reporting
errors might become obvious.
Required by #865. This doesn't introduce any method to view which
parameters are accessed.
We record which config items are accessed even if we don't intend to
output them, as we assume it will be a relatively cheap operation.
