* Pick up comments between visibility modifier and item name
I don't think this hurts to fix. #2781, which surfaced this issue, has
a number of comments relating to similar but slightly different issues
(i.e. dropped comments in other places). I can mark #2781 as closed and
then will open new issues for the comments that are not already resolved
or tracked.
Closes#2781
* fixup! Pick up comments between visibility modifier and item name
* fixup! Pick up comments between visibility modifier and item name
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!()`)
