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.
Preparation for #865, which proposes adding a flag which outputs which
config options are used during formatting.
This PR should not make any difference to functionality. A lot of this
was search-and-replace.
Some areas worthy of review/discussion:
- The method for each config item returns a clone of the underlying
value. We can't simply return an immutable reference, as lots of
places in the code expect to be able to pass the returned value as
`bool` (not `&bool). It would be nice if the `bool` items could
return a copy, but the more complex types a borrowed reference... but
unfortunately, I couldn't get the macro to do this.
- A few places (mostly tests and `src/bin/rustfmt.rs`) were overriding
config items by modifying the fields of the `Config` struct directly.
They now use the existing `override_value()` method, which has been
modified to return a `Result` for use by `src/bin/rustfmt.rs`. This
benefits of this are that the complex `file_lines` and `write_mode`
strings are now parsed in one place (`Config.override_value`) instead
of multiple. The disadvantages are that it moves the compile-time
checks for config names to become run-time checks.
* Add custom comments
This allows users to use custom comments such as
```
//@ this is a custom comment
//@ with multiple lines
```
without having them destroyed by rustfmt.
* Fix issues with empty lines
* Check non-whitespace right after custom comments
Only change multiline comments of the form
```rust
/*
* Text
*/
```
while not affecting comments of the form
```rust
/*
Text
*/
```
when normalize_comments is off. In the first case,
we have a known character we can align against, while
we don't have one in the second case.
Before, we have converted the second form into the first,
but this is against the spirit of normalize_comments being
turned off.
Fixes#956
* Handle attributes (including doc comments) on inline modules
Closes#22Closes#684
* Tweak the rules for changing indentation in comments (to do it less often).
We will no longer break in the middle of words, only at whitespace or punctuation.
This means we sometimes over-run, but that seems better than some of the bad splits we see.
Closes#369
When the reformatted code doesn't contain the same quantity of comments
as the original code, use the original code instead of the reformatted
code.
This is done for all expressions and `let` statements.
This should be used at the finest grained level possible, to avoid that
a small disappearing comment prevents a big chunk of code to be
reformatted.
Kind of fixes (avoid disappearing comments, but prevents a good
formatting is such case) #285#225#563#743
