The `isatty` crate has been deprecated and a replacement has been
released for it called `atty`. It offers a nicer API and the code
change to adapt is trivial.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Why?:
- Conceptually it sounds right
- Absolutely all write modes where doing it anyway
- It was done several times in some in case
- It greatly simplify the code
* 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.
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
`format_code_block` formats the given `code_snippet` by enclosing it inside
`fn main` block. Previously we did not add indentation to the `code_snippet`
before formatting it. This works fine as long as we can format the given
`code_snippet`, but when the code block has unformattable macro, they gets
unindented. This commit fixes it by adding proper indentation before formatting
the `code_snippet`.
For example, when formatting the following code block,
```rust
some_macro!(pub fn foo() {
println!("Don't unindent me!");
});
```
previously we enclosed it like this:
```rust
fn main() {
some_macro!(pub fn foo() {
println!("Don't unindent me!");
});
}
```
with this PR, we will enclose it like this:
```rust
fn main() {
some_macro!(pub fn foo() {
println!("Don't unindent me!");
});
}
```
Closes#2523.
This commit adds `overflow` module. This module provides two APIs.
`rewrite_with_parens` is basically the same as `rewrite_call_inner`.
`rewrite_with_angle_brackets` is used for rewriting generics and types.
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",
]
```
This allows occurrences of `{` and `}` within `{}` placeholders in the
template, and also for having literal `{` and `}` in the template by
means of escaping (`\{`).
Unbalanced, unescaped `}` at the toplevel is a syntax error which
currently triggers a panic; I'll add proper error handling as I move the
license template parsing code into the config parsing phase.
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! :)
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?
