mangling for non-type template arguments of class type

[zygoloid]

Standard paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf

C++20 adds the ability for near-arbitrary class types to be used as the type of non-type template arguments. We need a mangling for these.

We are guaranteed that such classes are not unions and do not contain unions, so perhaps the simplest approach would be to emit pseudo-aggregate-initialization syntax for the flattened sequence of subobjects:

struct A {
  int x;
  int : 0;
  int y;
};
struct B : A { int arr[2]; };
template<auto> struct Q {};
void f(Q<B{1, 2, 3, 4}>); // mangled as _Z1f1QIXtl1BLi1ELi2ELi3ELi4EEEE

These are going to get very long, very fast, so we might want an alternative representation for large objects. One intended use case is for things like:

template<size_t N> struct str {
  constexpr str(const char *p) : data{} { for (int n = 0; *p; ++p) data[n] = *p; }
  char data[N];
};
template<size_t N> str(const char (&)[N]) -> str<N>;
template<str S> struct R {};
void f(R<"some very long string here">);

... and encoding this with a long sequence of Lic123E manglings seems highly undesirable. This ties into another open question: how should string literal expressions be mangled? (Currently we say that we only mangle the length, which is insufficient.) Reusing whatever mangling we use for string literals as the mangling for char arrays within a non-type template argument might be wise. Alternatively / additionally, we could emit only a (suitably secure) hash of the literal value if it's very long.

---

Another form of mangling is also required here: all non-type template arguments with the same value throughout the entire program are lvalues denoting the same object, so we need a mangling for the global constant holding that object. Proposal:

<special-name> ::= TA <template-arg> # template parameter object for argument <template-arg>

Eg:

template<auto V> const auto *p = &V;
// mangled as _Z1pIXtl1BLi1ELi2ELi3ELi4EEEE
// initialized as pointer to _ZTAXtl1BLi1ELi2ELi3ELi4EEE
template const B *p<B{1, 2, 3, 4}>;

[daveedvdv]

On Oct 1, 2018, at 10:21 PM, Richard Smith ***@***.***> wrote: Standard paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf> C++20 adds the ability for near-arbitrary class types to be used as the type of non-type template arguments. We need a mangling for these. We are guaranteed that such classes are not unions and do not contain unions, so perhaps the simplest approach would be to emit pseudo-aggregate-initialization syntax for the flattened sequence of subobjects: struct A { int x; int : 0; int y; }; struct B : A { int arr[2]; }; template<auto> struct Q {}; void f(Q<B{1, 2, 3, 4}>); // mangled as _Z1f1QIXtl1BLi1ELi2ELi3ELi4EEEE

Looks like a good starting point to me.

These are going to get very long, very fast, so we might want an alternative representation for large objects. One intended use case is for things like: template<size_t N> struct str { constexpr str(const char *p) : data{} { for (int n = 0; *p; ++p) data[n] = *p; } char data[N]; }; template<size_t N> str(const char (&)[N]) -> str<N>; template<str S> struct R {}; void f(R<"some very long string here">); ... and encoding this with a long sequence of Lic123E manglings seems highly undesirable. This ties into another open question: how should string literal expressions be mangled? (Currently we say that we only mangle the length, which is insufficient.) Reusing whatever mangling we use for string literals as the mangling for char arrays within a non-type template argument might be wise.

Right. (Or vice versa, though that seems wasteful.)

Alternatively / additionally, we could emit only a (suitably secure) hash of the literal value if it's very long.

I think we should definitely do that (“additionally” rather than “alternatively”, IMO). Ideally, we should still be able to provide a helpful demangling for the initial part of the composite value.

Another form of mangling is also required here: all non-type template arguments with the same value throughout the entire program are lvalues denoting the same object, so we need a mangling for the global constant holding that object. Proposal: <special-name> ::= TA <template-arg> # template parameter object for argument <template-arg> Eg: template<auto V> const auto *p = &V; // mangled as _Z1pIXtl1BLi1ELi2ELi3ELi4EEEE // initialized as pointer to _ZTAXtl1BLi1ELi2ELi3ELi4EEE template const B *p<B{1, 2, 3, 4}>;

LGTM. Daveed

[zygoloid]

See also issue #64 for mangling string literals. We should consider whether there's a generalized technique for hashing large objects that we can share between that and this. In this case, an additional complication is that we don't necessarily have a concrete value -- pointer subobjects of the non-type template argument value need to be encoded symbolically. Perhaps we could (in both cases) compute the full mangling and then reduce it to a prefix and a hash if it's longer than some threshold.

[jicama]

And when a string is used to initialize a member of character array type, it should be mangled the same as that member initialized by a braced-init-list, since the semantic effect is the same. That is, for

struct A { char c[4]; };
template < A a> struct B { };
void f(B<A{"FOO"}>) {}
void g(B<A{'F', 'O', 'O', '\0'}>) {}

The types of f and g are the same, and should mangle the same.

[zygoloid]

We are guaranteed that such classes are not unions and do not contain unions

This is no longer the case; presumably using a designated initialization mangling to identify the active member would be reasonable. This leaves open the question of how to mangle a union with no active member. tl1UE (U{}) would be available for this use but doesn't really seem "right". Maybe Li1UE?

[zygoloid]

GCC has implemented some variant of this proposal. Specifically:

• They appear to use tl <type> <expression>* E for classes, but drop some trailing elements.
• They appear to use tl <type> di <source-name> <expression>* E for unions.
• They appear to use tl <type> <expression>* E for arrays, but unpredictably[1] drop some (but not all) trailing elements that are the same as a zero-initialized element.
• References to subobjects are mangled using dt, ix, but derived-to-base conversions are not mangled resulting in collisions[2].
• Pointers to subobjects are mangled as ad + a reference expression.
• Pointers-to-data-members are sometimes mangled as offsets (LM1Xi0E), sometimes as an "address-of" operation (adL_ZN1B1nEE).
• Pointers-to-member-functions are mangled as structs (tlM1BFivEadL_ZNS1_1nEvEE).
• The template parameter object itself uses the proposed _ZTAX...E mangling.

I'd suggest we make the following modifications to that scheme before adopting it:

1: Use L <type> E to represent uninitialized objects and unions with no active member. (GCC doesn't appear to support these in template arguments yet.)
2: Omit trailing elements from the three tl manglings if and only if every scalar subobject is initialized to zero and every union with members has its first member active.
3: Use the scheme in #47 for pointers, references, and pointers-to-members. In particular, disambiguate references to base members where necessary, and mangle pointers-to-members semantically rather than (sometimes) based on the generated constant value.

[1]:

union Q { int n, m; constexpr Q(int k) : n(k) {} constexpr Q() : n(0) {} };
struct A { Q arr[6]; };
template<A a> struct B {};

// Mangled as _Z1f1BIXtl1AtlA6_1QtlS1_di1nLi1EEtlS1_di1nLi2EEtlS1_di1nLi3EEtlS1_di1nLi0EEEEEE
// Note that Q(0) element is mangled but Q() elements are not.
void f(B<A{1, 2, 3, 0}>) {}

[2]:

struct A { int n; };
struct B : A { int n; } b;

struct D { int &r; };
template<D> int x;
// These different variables mangle the same.
int &y = x<D{b.A::n}>;
int &z = x<D{b.B::n}>;

[zygoloid]

When mangling a class member, GCC appears to remove top-level cv-qualifiers. Example:

struct A { const int a; int *const b; int c; };
template<A> void f() {}
template void f<A{.c = 1}>();

... is mangled as _Z1fIXtl1ALi0ELPi0ELi1EEEEvv, not as _Z1fIXtl1ALKi0ELKPi0ELi1EEEEvv. It seems reasonable to follow that; the cv-qualifiers are irrelevant to the value.