clang-format breaks for a member function with both a reference qualifier and a trailing requires clause

[cgnitash]

From clang-format 19, member functions containing both a reference qualifier and a trailing requires clause, results in broken formatting until the closing brace of the following member function.

cat test.cpp

template <int n> struct S
{
  void f() & requires(n == 1) {}

  // some comment
  void g() {}
};

clang-format-19 test.cpp

template <int n> struct S
{
  void f() & requires(n == 1) {}

      // some comment
      void g()
  {
  }
};

Note the indentation of the // some comment and void g(), which is obviously incorrect. (Additional custom brace wrapping options are also ignored after the definition of f, but the above is just a simplified example without a custom .clang-format).

The expected output is what clang-format 18 gives:

clang-format-18 test.cpp

template <int n> struct S
{
  void f() &
  requires(n == 1)
  {
  }

  // some comment
  void g() {}
};

This bug doesn't manifest when using explicit object parameters, so there is a workaround for now, but it would nice to avoid that change.

[llvmbot]

@llvm/issue-subscribers-clang-format

Author: None (cgnitash)

From clang-format 19, member functions containing *both* a reference qualifier and a trailing requires clause, results in broken formatting until the closing brace of the following member function. > cat test.cpp ``` template <int n> struct S { void f() & requires(n == 1) {}

// some comment
void g() {}
};

> clang-format-19 test.cpp

template <int n> struct S
{
void f() & requires(n == 1) {}

  // some comment
  void g()

{
}
};

Note the indentation of the `// some comment` and `void g()`, which is obviously incorrect. (Additional custom brace wrapping options are also ignored after the definition of `f`, but the above is just a simplified example without a custom .clang-format).

The expected output is what clang-format 18 gives:
> clang-format-18 test.cpp

template <int n> struct S
{
void f() &
requires(n == 1)
{
}

// some comment
void g() {}
};

This bug doesn't manifest when using explicit object parameters, so there *is* a workaround for now, but it would nice to avoid that change.
</details>

[owenca]

Bisected it to 9b68c09. @rymiel