[clang] [clang-tools-extra] [llvm] [Clang] Add __builtin_type_pack_dedup template to deduplicate types in template arguments (PR #106730)

[Matheus Izvekov via cfe-commits]

================
@@ -3158,6 +3161,33 @@ checkBuiltinTemplateIdType(Sema &SemaRef, BuiltinTemplateDecl *BTD,
     int64_t N = Index.getExtValue();
     return Ts.getPackAsArray()[N].getAsType();
   }
+  case BTK__type_pack_dedup: {
+    assert(Converted.size() == 2 && "__builtin_type_pack_dedup should be given "
+                                    "a template and a parameter pack");
+    TemplateArgument Template = Converted[0];
+    TemplateArgument Ts = Converted[1];
+    if (Template.isDependent() || Ts.isDependent())
----------------
mizvekov wrote:

You are right that we can't drop out the builtin template specialization just yet if any of the arguments are dependent.

But we can still unique the list in that case. This actually even applies for unexpanded packs as well.

One advantage I see is that you would avoid the possibility of the user introducing multiple overloads that are equivalent, which you wouldn't be able to partial order later.

Ie

```C++
template <class...> struct A;
template <class T> void f(__builtin_type_pack_dedup<A, T>) {}
template <class T> void f(__builtin_type_pack_dedup<A, T, T>) {}
```
This would be ill-formed because `f` is being redefined.

This also increases the ABI stability for the same reason. If the user introduces another repeated template argument, it's still results in the same templated entity with the same mangling.

> Do you feel strongly that we need to do (3) ?

See above.

> I do not think we can avoid this completely (see above) and it's not unprecedented: other builtin templates can already appear in mangling too when the arguments are dependent. So I do think it's necessary and I'm not sure which problems it carries.

Right, it's not completely unavoidable, but at least for the dependent template name case that we can resolve early, it makes it so this builtin can be introduced without causing an ABI break.

https://github.com/llvm/llvm-project/pull/106730