Foreign function blocks dropped #4313
Labels
bug
Panic, non-idempotency, invalid code, etc.
Comments
ayazhafiz
added a commit
to ayazhafiz/rustfmt
that referenced
this issue
Jul 10, 2020
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 rust-lang#4313
dtolnay
pushed a commit
to dtolnay-contrib/rustfmt
that referenced
this issue
Nov 29, 2020
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 rust-lang#4313
calebcartwright
pushed a commit
that referenced
this issue
Nov 29, 2020
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
rustfmt drops block associated with a foreign function
To Reproduce
Formatting
gives
Context: rust-lang/rust#74204
Expected behavior
The formatting makes the code semantically correct, but causes a loss of information. I think rustfmt should preserve the block, if it has access to it.
Meta
The text was updated successfully, but these errors were encountered: