[clang] deprecate frelaxed-template-template-args, make it on by default

[mizvekov]

Summary

A resolution to the ambiguity issue created by P0522, which is a DR solving
CWG 150, did not come as expected.

There is reasonable code in the wild which would be affected by this,
so we implement a workaround to disambiguate those cases:
We pick as the more specialized partial specialization the one
which has the first template argument of template specialization type
with a smaller number of arguments.

The driver flag is deprecated with a warning, and it will not have any effect.

Signed-off-by: Matheus Izvekov <[e-mail]>

[mizvekov]

.

[mizvekov]

.

[mizvekov]

.

[rsmith]

clang/www/cxx_status.html

816–817

We should list this as implemented in Clang 4, with a footnote saying that until Clang 14 you need to pass an additional flag, like we do for char8_t: https://clang.llvm.org/cxx_status.html#p0482

[mizvekov]

• Clarify that P0522 was implemented in Clang 4, explain in footnote.
• Add DR link.
• C++17 section goes all green, so we fold it!

[rsmith]

Thanks, let's land this and see how it goes.

[mizvekov]

rebase, one last CI run.

[yaxunl]

This caused regression in Thrust:

/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/detail/type_traits/pointer_traits.h:178:20: error: ambiguous partial specializations of 'pointer_element<thrust::pointer<void, thrust::detail::seq_t>>'
  typedef typename pointer_element<Ptr>::type    element_type;
                   ^
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/detail/raw_pointer_cast.h:27:26: note: in instantiation of template class 'thrust::detail::pointer_traits<thrust::pointer<void, thrust::detail::seq_t>>' requested here
typename thrust::detail::pointer_traits<Pointer>::raw_pointer
                         ^
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/system/hip/detail/malloc_and_free.h:79:18: note: while substituting deduced template arguments into function template 'raw_pointer_cast' [with Pointer = thrust::pointer<void, thrust::detail::seq_t>]
        result = thrust::raw_pointer_cast(thrust::malloc(thrust::seq, n));
                 ^
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/detail/type_traits/pointer_traits.h:40:10: note: partial specialization matches [with Ptr = thrust::pointer, Arg1 = void, Arg2 = thrust::detail::seq_t]
  struct pointer_element<Ptr<Arg1,Arg2> >
         ^
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/detail/type_traits/pointer_traits.h:46:10: note: partial specialization matches [with Ptr = thrust::pointer, Arg1 = void, Arg2 = thrust::detail::seq_t, Arg3 = thrust::use_default]
  struct pointer_element<Ptr<Arg1,Arg2,Arg3> >
         ^
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/rocThrust/thrust/../thrust/detail/type_traits/pointer_traits.h:52:10: note: partial specialization matches [with Ptr = thrust::pointer, Arg1 = void, Arg2 = thrust::detail::seq_t, Arg3 = thrust::use_default, Arg4 = thrust::use_default]
  struct pointer_element<Ptr<Arg1,Arg2,Arg3,Arg4> >

This seems to match the removed documentation about "The change to the standard lacks a corresponding change for template partial ordering, resulting in ambiguity errors for reasonable and previously-valid code. This issue is expected to be rectified soon." However, since it was removed, does that mean there will be no changes for template partial ordering?

[mizvekov]

Thanks for reporting this!

This change in the standard was worked a long time ago, and there was some expectation that there would be follow up work to add new partial ordering rules so that reasonable code would keep working. But the person behind that effort stopped participating in the process, so this fell into the cracks.

We tried with this patch here to see if the rules would just work out as intended. Another option, which I believe is what GCC does, is to not do the DR part and apply it only to c++17 and later.
However the breakage example you posted seems to be from a CUDA library which is not usable in the GCC ecosystem, is that correct? And that this library might be modern and used with newer standard as well?

If that is the case, the GCC solution might not be good for us anyway, and the simplest thing would be to just implement some new rules.

[mizvekov]

Feel free to revert it if this is blocking you. I don't seem to find a way to do it via web interface, so I need more time to have access to a machine that can do it

[yaxunl]

In D109496#3103963, @mizvekov wrote:

Thanks for reporting this!

This change in the standard was worked a long time ago, and there was some expectation that there would be follow up work to add new partial ordering rules so that reasonable code would keep working. But the person behind that effort stopped participating in the process, so this fell into the cracks.

We tried with this patch here to see if the rules would just work out as intended. Another option, which I believe is what GCC does, is to not do the DR part and apply it only to c++17 and later.
However the breakage example you posted seems to be from a CUDA library which is not usable in the GCC ecosystem, is that correct? And that this library might be modern and used with newer standard as well?

If that is the case, the GCC solution might not be good for us anyway, and the simplest thing would be to just implement some new rules.

The regression happens with rocThrust, which is CUDA Thrust ported to HIP language. However, I think the same issue would happen to CUDA Thrust.

These libraries need to work with C++17, therefore it is better to implement some new rules.

[yaxunl]

In D109496#3103978, @mizvekov wrote:

Feel free to revert it if this is blocking you. I don't seem to find a way to do it via web interface, so I need more time to have access to a machine that can do it

I will revert it since it is blocking us. Thanks.

[mizvekov]

Implement workaround.

[mizvekov]

.