clang-format changed output for template arguments in trailing return types

[ilya-biryukov]

After 438ad9f2bf25575c474313de4ad85a5da6f69e4c (found by bisecting), clang-format started producing a slightly different formatting in some cases with template arguments in trailing return types.

The new formatting does not necessarily look bad, but I wanted to understand if the new formatting is expected or not. I am not an expert in the intricacies of the various setting that clang-format has, so asking experts. @owenca, could you let us know if you feel this is a regression or not?

cc @kadircet

All examples are formatted clang-format -style=google

Input:

template <typename F, typename... Args>
  requires internal::future::decayed_produces_co<F, Args...>
explicit Future(F&&, Args&&...) -> Future<
    internal::coroutine_result_type<std::decay_t<F>, std::decay_t<Args>...>>;

Expected (aka before)

template <typename F, typename... Args>
  requires internal::future::decayed_produces_co<F, Args...>
explicit Future(F&&, Args&&...) -> Future<internal::coroutine_result_type<
                                    std::decay_t<F>, std::decay_t<Args>...>>;

Actual (aka after)

template <typename F, typename... Args>
  requires internal::future::decayed_produces_co<F, Args...>
explicit Future(F&&, Args&&...) -> Future<
    internal::coroutine_result_type<std::decay_t<F>, std::decay_t<Args>...>>;

---

And here's another more extreme example. Expected (before):

struct Foo {
  template <typename Adaptor>
  auto With(Adaptor&& adaptor) & -> status_internal::PurePolicy<
                                     Adaptor, StatusBuilder&> {}
};

Actual (after):

struct Foo {
  template <typename Adaptor>
  auto With(Adaptor&& adaptor) & -> status_internal::PurePolicy<
      Adaptor, StatusBuilder&> {}
};

[llvmbot]

@llvm/issue-subscribers-clang-format

Author: Ilya Biryukov (ilya-biryukov)

After 438ad9f2bf25575c474313de4ad85a5da6f69e4c (found by bisecting), clang-format started producing a slightly different formatting in some cases with template arguments in trailing return types. The new formatting does not necessarily look bad, but I wanted to understand if the new formatting is expected or not. I am not an expert in the intricacies of the various setting that clang-format has, so asking experts. @owenca, could you let us know if you feel this is a regression or not? cc @kadircet All examples are formatted `clang-format -style=google` Input: ```cpp template <typename F, typename... Args> requires internal::future::decayed_produces_co<F, Args...> explicit Future(F&&, Args&&...) -> Future< internal::coroutine_result_type<std::decay_t<F>, std::decay_t<Args>...>>; ``` Expected (aka before) ```cpp template <typename F, typename... Args> requires internal::future::decayed_produces_co<F, Args...> explicit Future(F&&, Args&&...) -> Future<internal::coroutine_result_type< std::decay_t<F>, std::decay_t<Args>...>>; ``` Actual (aka after) ```cpp template <typename F, typename... Args> requires internal::future::decayed_produces_co<F, Args...> explicit Future(F&&, Args&&...) -> Future< internal::coroutine_result_type<std::decay_t<F>, std::decay_t<Args>...>>; ``` <hr> And here's another more extreme example. Expected (before): ```cpp struct Foo { template <typename Adaptor> auto With(Adaptor&& adaptor) & -> status_internal::PurePolicy< Adaptor, StatusBuilder&> {} }; ``` Actual (after): ```cpp struct Foo { template <typename Adaptor> auto With(Adaptor&& adaptor) & -> status_internal::PurePolicy< Adaptor, StatusBuilder&> {} }; ```

[owenca]

After 438ad9f (found by bisecting), clang-format started producing a slightly different formatting in some cases with template arguments in trailing return types.

The new formatting does not necessarily look bad, but I wanted to understand if the new formatting is expected or not. I am not an expert in the intricacies of the various setting that clang-format has, so asking experts. @owenca, could you let us know if you feel this is a regression or not?

This is not a regression. The "new" behavior you see now is actually the same as that before e00d32afb9d33a1eca48e2b041c9688436706c5b, which 438ad9f2bf25575c474313de4ad85a5da6f69e4c has in effect reverted.

[ilya-biryukov]

Thanks for confirming!