Fully specify the mangling of non-type template arguments

[rjmccall]

This includes the material from #47 (non-type template arguments), #63 (class constants), and the template-param-decl portions of #85 (C++20 lambda-expressions).

@zygoloid gets credit for most of this, although I've made a few substantive changes from his suggestions.

[zygoloid]

Suggested change

	Null pointers and member pointers are mangled as as a literal
	Null pointers and member pointers are mangled as a literal

[zygoloid]

Suggested change

	initiializer sequence</a> for the contents of the type.
	initializer sequence</a> for the contents of the type.

[zygoloid]

Suggested change

	field and class names into the ABI. If the offset is zero, it can
	be omitted.
	field and class names into the ABI. If the offset is zero, it is
	omitted.

[zygoloid]

Clang and GCC don't do this flattening; this would be an ABI change for both: https://godbolt.org/z/nzWP13MMf ... but I think these manglings are new enough that we can afford to change them.

For the most part, this flattening seems good: it'll make manglings shorter in some cases, and avoids encoding details of the internal structure of the type (eg, empty base classes and additional layers of base class wrapping don't affect the mangling). But it also will cause problems for the tail-dropping below, for the motivating cases such as:

struct StringParam {
  char data[256];
  int length;
};
template<StringParam str> void f();

... where the rule used by Clang and GCC would mangle f<{"foo", 3}>() relatively compactly (_Z1fIXtl11StringParamtlA256_cLc102ELc111ELc111EELi3EEEEvv) but this flattening will mean that we can't do the tail-dropping any more and will encode 253 additional zero Lc0Es before the Li3E.

Perhaps we can keep the flattening of non-union class types and remove the flattening of arrays? Because we don't need precise typing, we can use il instead of tl here, rather than encoding the array type as Clang and GCC currently do.

[rjmccall]

Not flattening arrays so that we can use tail optimization makes sense to me; I can write that up.

[zygoloid]

I think we should use il instead of tl <type> when precise typing is not required. This would make a difference when mangling a union member that is itself of class type.

[rjmccall]

That would be a total break with the provisional manglings implementations have been using for class template arguments.

[zygoloid]

Hm, I suppose this would change all manglings for (eg) class templates with non-type parameters of class type. That said, the addition of flattening is a pretty big change too. How big a break are we prepared to accept here? Unlike some of the other manglings we're changing in this PR, these ones only affect C++20 onwards.

[zygoloid]

Something that came up in discussion on #111: what should we do with array-to-pointer decay, in the case where a precise type is not needed? This has been valid since C++98, as an exception to the old general rule that a pointer template parameter couldn't point to a subobject. For example:

int arr[32];
template<int *> struct X {};
void f(X<arr>) {}

GCC mangles this as _Z1f1XIXadL_Z3arrEEE. Clang already implements part of this PR and uses an adsoiL_Z3arrE mangling. But this seems like an avoidable break for GCC: as a very special case, we could instead say that a pointer to the first element of an array is mangled the same as the array itself when precise typing isn't needed and the parameter is not of type cv void *. On the other hand, Clang already took the ABI break here and it seems to not have been problematic, so maybe it's not worth adding a special case.

[bolshakov-a]

Thanks for preparing this! I have some questions inline.

[bolshakov-a]

Anonymous structs are a part of the C language standard but not of the C++ standard currently, AFAIK. Is the suggested change for compiler extensions?

[bolshakov-a]

Non-uniform indentation of the comment.

[bolshakov-a]

Suggested change

	<code class=mangle>ad</code>. The notional type of this expression
	<code class=mangle>ad</code>). The notional type of this expression

[bolshakov-a]

Should mc mangling contain class type or pointer-to-member type, as in this example?

[bolshakov-a]

Suggested change

	has an active union member member and (if so) which one. As
	has an active union member and (if so) which one. As

[bolshakov-a]

Have you lost curly braces in template arguments?

[jicama]

is it intended to change the mangling of C++98 code like

template <class T, T V> T f() { return V; }
int main() { return f<int,42>(); }

? Most of the templates I see that use <typename T, T V> are classes and so unaffected, but there's at least one internal helper function in libstdc++ that will be changed.

[jicama]

Saying that only a type parameter pack can be natural for an empty argument pack also changes the mangling of C++11 code like

template <int i> int max() { return i; }
template <int i, int j, int... rest> int max()
{ 
  int sub = max<j, rest...>();
  return i > sub ? i : sub;
}
int main() {  return max<1,2,3>(); }

and requiring template template args to have the same template head changes the mangling of C++11 code like

template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
template <typename> struct A { }; 
int main() { f<A,int>(); }

[rjmccall]

Some mangling changes for function templates are unavoidable, yeah. Even in C++98, we have the conflict:

// _Z3fooIiLi0EEvv
template <class T, T N> void foo() {}
template void foo<int, 0>();

// _Z3fooIiLi0EEvv
template <class T, int N> void foo() {}
template void foo<int, 0>();

You can't have these both in the same translation unit, but they're formally different templates and need to be mangled differently.

[rjmccall]

Alright, I should take another look at this.