duplicating `where` clauses that contains (unused) braces

[peter-lyons-kehl]

This affects very specialized and a few months outdated codebases that

• had to use #[allow(unused_braces)] (before it was recently lifted) to invoke macros from where clauses, and
• there is an asterisk-based or two slash-based comment in the struct or enum definition.

Hence likely to be a lower priority. But I'm reporting this in case it's connected to any other/potential bigger issues.

Run cargo fmt from recent nightly (noticed with nightly as of Feb 2, 2023, chances are the problem existed before; the bug still exists as of Feb 15, 2023) on a project with lib.rs containing the following (which does compile; or get the code from https://github.com/peter-kehl/fmt_bug_where_braces):

#![allow(incomplete_features)]
#![feature(generic_const_exprs)]

macro_rules! num_slots {
    ($c:expr) => {
        1
    };
}

#[allow(dead_code)]
#[allow(unused_braces)]
struct S<const C: usize>
where
    [(); { num_slots!(C) }]:, {
    /* An asterisk-based, or a double-slash-prefixed, comment here is
       required to trigger the fmt bug.

    A single-line triple-slash-prefixed comment (with a field following it) is not enough - it will not trigger the fmt bug.

    Side note: If you have a combination of two, or all three of the
    above mentioned types of comments here, some of them disappear
    after `cargo fmt`.

    The bug gets triggered even if a field definition following the
    (asterisk-based, or a double-slash-prefixed) comment, too.
    */
}

That injects an extra line num_slots!(C) }]:, {, which makes the project not compile anymore:

cargo fmt
git diff
diff --git a/src/lib.rs b/src/lib.rs
index ce30fe0..44f77eb 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -12,6 +12,7 @@ macro_rules! num_slots {
 struct S<const C: usize>
 where
     [(); { num_slots!(C) }]:, {
+    num_slots!(C) }]:, {
     /* An asterisk-based, or a double-slash-prefixed, comment here is
        required to trigger the fmt bug.

(Initially reported as rust-lang/rust#107610. The source that triggered the bug is not a part of rust-lang/rust itself, but it's from my experimentation.)

[peter-lyons-kehl]

Thank you for the fix.

When is this likely to be in nightly, or do I need any special steps?

I'm on Manjaro/Arch Linux x64, using rustup as it comes from Manjaro/Arch packages. rustup update shows:
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.69.0-nightly (7aa413d59 2023-02-19).

rustup default 
nightly-x86_64-unknown-linux-gnu (default)

But, when I run cargo fmt, I still have this problem (duplicated and misplaced part of where bound).

[peter-lyons-kehl]

And, while we're on it, and if you happen to know:
I have this problem when building my fork of rust-lang/rust with its x.py (I actually use x). In my config.toml I have channel = "nightly". Would that be using the version of nightly that I have, or does it pull nightly for its own purposes and independent of nightly that I use for ordinary development?

[ytmimi]

When is this likely to be in nightly, or do I need any special steps?

@peter-kehl rustfmt is incorporated into the rust-lang/rust repo via a git subtree so you won't see changes made to rust-lang/rustfmt appear on nightly until the rustfmt team performs a subtree sync with the upstream rust-lang/rust repo. We performed a sync recently, so I'm not sure when we'll perform another one.

You can try to install rustfmt from source, but be aware that you'll need to build rustfmt with the nightly compiler version listed in rustfmt's rust-toolchain file, and you'll also need to have the llvm-tools, and rustc-dev components installed as well. Those components are also listed in the rust-toolchain file.

I have this problem when building my fork of rust-lang/rust with its x.py

Unfortunately I don't know how to help with x.py related issues, but maybe you can get some help by reaching out on Zulip

[peter-lyons-kehl]

Thank you. All fine. Take care.