Indentation in macro is increased in each run (non-idempotent)

[JanBeh]

The following code is given:

macro_rules! m {
    ($x:tt) => {
        type T = $x
        where
            A: B;
    };
}

Running rustfmt results in:

macro_rules! m {
    ($x:tt) => {
        type T = $x
                where
                    A: B;
    };
}

Running it again:

macro_rules! m {
    ($x:tt) => {
        type T = $x
                        where
                            A: B;
    };
}

And so on.

The following smaller example is idempotent, however:

 macro_rules! m {
     ($x:tt) => {
-        type T = $x
+        type $x
         where
             A: B;
     };

I'm using:

rustfmt 1.5.2-nightly (b2b34bd8 2023-06-06)

The above example is a minimal example to reproduce the problem. The full code I used can be found here.

[ytmimi]

@JanBeh thanks for reaching out!

This issue stems from rustfmt's lack of support for formatting associated types using the new recommend style where the where clause come after the type name.

For example:

type Assoc<Params> = Type where WhereBounds;
type Assoc<Params> where WhereBounds = Type; // deprecated, prefer the form above

This is related to #5580

As a workaround you might consider using the deprecated style to avoid this issue (which rustfmt handles just fine):

macro_rules! m {
    ($x:tt) => {
        // FIXME: waiting till https:/rust-lang/rustfmt/issues/5778 is resolved.
        type T
        where
            A: B,
        = $x;
    };
}

Alternatively, you could use the #[rustfmt::skip] attribute:

#[rustfmt::skip]
macro_rules! m {
    ($x:tt) => {
        type T = $x
        where
            A: B;
    };
}

[calebcartwright]

Thanks for reaching out and creating a minimal repo! I'm going to close this, however, because as Yacin noted it's a duplicate of couple known items tracked elsewhere; in addition to #5580 rustfmt has a bug (#5062/#5044) where if it encounters something it doesn't know how to format within a macro it produces that non-idempotent

[JanBeh]

Thank you very much for the references and the hint to use the old-style syntax. I figured there were somes issues with non-idempotence, but I wasn't sure which of those (if any) was covered by my case.