Previously the indetation of a line was compared with the configured
number of spaces per tab, which could cause lines that were formatted
with hard tabs not to be recognized as indented ("\t".len() < " ".len()).
Closes#4152
A code like
```rust
extern "C" {
fn f() {
fn g() {}
}
}
```
is incorrect and does not compile. Today rustfmt formats this in a way
that is correct:
```rust
extern "C" {
fn f();
}
```
But this loses information, and doesn't have to be done because we know
the content of the block if it is present. During development I don't
think rustfmt should drop the block in this context.
Closes#4313
* Added test cases
* Fixed if condition comment issue
* Fixed extern C issue
* Removed previous test case
* Removed tmp file
* honor the authors intent
* Changed the file name to its original name
* Removed extra whitespace
This commit partially reverts #3934, opting to create a span that covers
the entire body of a closure when formatting a closure body with a
block-formatting strategy, rather than having the block-formatting code
determine if the visitor pointer should be rewound. The problem with
rewinding the visitor pointer is it may be incorrect for other (i.e.
non-artificial) AST nodes, as in the case of #4382.
Closes#4382
We no longer flatten a block that looks like this:
```rust
match val {
pat => { macro_call!() }
}
```
Currently, rust ignores trailing semicolons in macro expansion in
expression position (see https://github.com/rust-lang/rust/issues/33953)
If this is changed, flattening a block with a macro call may break the
user's code - the trailing semicolon will no longer parse if the macro
call occurs immediately on the right-hand side of the match arm
(e.g. `pat => macro_call!()`)
