[clang-format] Changed formatting of trailing return type between version 18 and 19

[carlosgalvezp]

Hi!

We are testing bumping our clang-format installation from version 18 to 19, and notice a fair amount of churn, without changing the config file. In particular, this type of code:

auto foo(Type a, 
         Type b) -> std::enable_if<....>
{}

Gets transformed into:

auto foo(Type a, Type b) 
    -> std::enable_if<...>
{}

Do you know if there's a newly added option that controls this behavior, or what could be the reason for this change?

Thanks!

[llvmbot]

@llvm/issue-subscribers-clang-format

Author: Carlos Galvez (carlosgalvezp)

Hi!

We are testing bumping our clang-format installation from version 18 to 19, and notice a fair amount of churn, without changing the config file. In particular, this type of code:

auto foo(Type a, 
         Type b) -> std::enable_if<....>
{}

Gets transformed into:

auto foo(Type a, Type b) 
    -> std::enable_if<...>
{}

Do you know if there's a newly added option that controls this behavior, or what could be the reason for this change?

Thanks!

[rymiel]

You have to provide a config and the full lines of code (we don't need the whole file)

I suspect it might be related to e00d32a and 438ad9f and might already be fixed but we can't tell you unless you provide more info or unless you test on main

[carlosgalvezp]

Sure, here it goes. This happens on the default configuration, without any .clang-format file. Comparing 18.1.8 vs 19.1.1:

$ cat test.cpp
template <class T>
auto foo(Foo<T> const& lhs,
         Foo<T> const& rhs) -> std::enable_if_t<T::size == 2, bool>
{
    return bar(lhs, rhs);
}

$ clang-format-18 test.cpp
template <class T>
auto foo(Foo<T> const &lhs,
         Foo<T> const &rhs) -> std::enable_if_t<T::size == 2, bool> {
  return bar(lhs, rhs);
}

$ clang-format-19 test.cpp
template <class T>
auto foo(Foo<T> const &lhs, Foo<T> const &rhs)
    -> std::enable_if_t<T::size == 2, bool> {
  return bar(lhs, rhs);
}

[carlosgalvezp]

It appears it happens in main as well:
https://godbolt.org/z/To7reY1nf

To clarify: I'm not saying this is worse or a bug, I'm just trying to understand if there's an option that controls this behavior. We'd like to bump our clang-format version with minimal changes to the code, and then in a follow-up patch flip the switch and change this particular case of formatting (if possible/wanted).

[rymiel]

So yeah, the change was caused by e00d32a and then reverted by 438ad9f (backported to 19 in bac3db3)

The format in clang-format 19 is how it is in every version of clang format since version 9, what happened in 18 was a mistake that has since been rectified. Unfortunately, that does mean that those changes are unavoidable, but hopefully shouldn't happen again when updating further

[carlosgalvezp]

Ok, thanks for the very quick response!