mangling of partially-substituted templates

[zygoloid]

The ABI document doesn't appear to give any guidance as to how to mangle partially-substituted portions of templates. For example, in:

template<typename ...T> struct A {
  template<typename ...U> void f(void (*...f)(T, U)) {}
};
void x(int, int);
void g() { A<int>().f(x); } 

how should A<int>::f be mangled?

EDG says: _ZN1AIJiEE1fIJiEEEvDpPFvT_T_E
GCC produces the same (but needs the template argument to be explicitly specified).
Clang gives: _ZN1AIJiEE1fIJiEEEvDpPFv_SUBSTPACK_T_E

Neither mangling preserves enough information to uniquely identify the target function.

The immediate context for this question is issues #47 and #63: after substituting in template arguments from an outer template, how do we mangle the signature of an inner template?

For example:

struct A { int x; };
template<A a> struct B {
  template<typename T> void f(decltype(T(a.x))) {}
};
void g() { B<A{0}>().f<int>(0); }

GCC mangles this as _ZN1BIXtl1AEEE1fIiEEvDTcvT_dtL_Z11_ZTAXtl1AEEE1xE (note the reference to the template parameter object in the middle, not just dttl1AE1x or similar); I think that's the right mangling here.

Another example:

class C {
  char buf[32];
public:
  constexpr const char *data() const { return buf; }
};
C c;
template<const char *p> struct X {};
void f(X<c.data()>) {}
template<const char *p> struct Y { template<typename T> void g(X<T(p)>); };
void h() { Y<c.data()>().g<const char*>({}); }

As I argued in #47, I don't think it's acceptable for us to include the private member name buf in the mangling of f. So similarly it doesn't seem acceptable for us to include the private member name buf in the mangling of Y<c.data()>::g. That suggests to me that the correct mangling to use for a substituted non-type template argument in general is the mangling of the <expression> or <expr-primary> that would appear in the corresponding <template-arg>.

The extension to more general substitution situations seems mostly straightforward: when a type is substituted, you mangle it as you would mangle the <type> in the corresponding <template-arg> (and indeed, presumably this mangling will almost always be a substitution referring back to that <template-arg>). And it would then presumably be appropriate to mangle a substituted pack as J <template-arg>* E.

So:

The first example is mangled as _ZN1AIJiEE1fIJiEEEvDpPFvJiET_E
In the second example, we produce the manglings:

_Z1f1XIXadsoKcL_Z1cEEEE (that is, f(X<&{c subobject of type 'const char' at offset 0}>))
_ZN1YIXadsoKcL_Z1cEEEE1gIPKcEEv1XIXcvT_adsoKcL_Z1cEEEE

Does that seem reasonable? (Note that I'm not suggesting adding any substitution candidates for the new manglings -- and in practice we'll see outer non-type and pack template arguments appearing multiple times in the same mangling. I don't think that we can do much about that, unless we support substitutions of expressions in general (ouch) or ask implementations to keep track of where they substituted into a signature (perhaps also ouch?) -- and in any case changes of that kind would be an ABI break.)

[rjmccall]

Your rule requires implementations to track whether a component template/type/expression in a substituted template member came from a substitution or not, right? Because if the program just wrote the original thing out longhand it'd get mangled differently? I don't know if that's intractable for anyone, or if we consider it problematic for other reasons.

[zygoloid]

I guess there are broadly two implementation options (assuming people mangle from their regular expression/type representation): either track where substitutions were performed so that they can be mangled appropriately, or ensure that substitution produces an expression that already has the same mangling as the form that we would require in a template argument mangling. But I think that's probably the case for any rule we might choose to pick.

The complicating factor here, if we follow both this and my suggestion in #47, would be that the latter option would now require an expression form corresponding to the so and mc manglings. Maybe that'll be a problem for someone?

[zygoloid]

Hm. This mostly only affects cases where we previously had no mangling and cases that are new in C++20, but the case where array-to-pointer decay is performed on a template argument would be an exception:

int arr[32];
template<int *P> struct A {
  template<typename T> void f(decltype((T)P)) {}
};
// Mangled as _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adL_Z3arrEE by GCC and ICC
// Mangled as _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_L_Z3arrEE by Clang 11 and before
// Mangled as _ZN1AIXadsoiL_Z3arrEEEE1fIPiEEvDTcvT_L_Z3arrEE by Clang 12 and after
// Mangled as _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE by this proposal
template void A<arr>::f<int*>(int*);

... but even in that case we have vendor divergence. Clang mangles as (int*)arr, whereas GCC and ICC mangle as (int*)&arr. Of these, the GCC/ICC mangling seems like it can't be right, because (int*)&arr isn't a constant expression, so isn't functionally equivalent to the substituted argument (and it's not correct to assign the same mangling to two non-functionally-equivalent expressions). The Clang mangling is plausible, but would be an aberration that we can probably avoid. It seems very likely to me to be OK in practice to change the mangling in this case.

[bolshakov-a]

Seems like the proposed approach has already been accepted in #131:

Typically, only references to function template parameters occurring
within the dependent signature of the template are mangled this way.
In other contexts, template instantiation replaces references
to template parameters with the actual template arguments, and mangling
should mangle such references exactly as if they were that template
argument.

Why this issue is still open? Or, have I misunderstood something?

But the last example seems confusing:
// Mangled as _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE by this proposal
It is evident that the substituted parameter mangling (adsoiL_Z3arrEE) differs from the corresponding template argument mangling (adL_Z3arrE)...

[zygoloid]

Why this issue is still open? Or, have I misunderstood something?

The first example in this issue (a partially-substituted pack) is still not handled. I suggested using J...E to mangle that, but that's not in the ABI document yet. Presumably we'd want something like:

<type> ::= J <template-arg>* E
<expression> ::= J <template-arg>* E
<template-prefix> ::= J <template-arg>* E

... though I'm not certain that's unambiguous, and it leaves open some questions:

• If the arity of the pack is 1, do you generate this mangling or just mangle the single expression?
• If the arity of the pack is 0, do you generate this mangling or omit the pack expansion entirely? (The language rules aren't really clear on this either.)

But the last example seems confusing: // Mangled as _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE by this proposal It is evident that the substituted parameter mangling (adsoiL_Z3arrEE) differs from the corresponding template argument mangling (adL_Z3arrE)...

See #47 / #166. adL_Z3arrE is not a correct mangling for an array-to-pointer decay. Under #166 the mangling is adsoiL_Z3arrEE (which is &arr[0] not &arr). For an example of why the current implementations' approaches are problematic, consider something like:

template<void *> struct X {};
int arr[32];
constexpr void *id(void *p) { return p; }
void f(X<id(arr)>) {} // #1
void f(X<id(&arr)>) {} // #2
void f(X<id(&arr[0])>) {} // #3

Here, #1 and #3 are definitions of the same function (the template argument is a pointer to the first element of the array arr), and #2 is a different function (the template argument is a pointer to arr itself). And yet, Clang and ICC mangle all three the same, and, most surprisingly, GCC mangles #1 and #2 the same and mangles #3 as &arr[0] using ix.

Though this does make me wonder if we should carve out a special case in #166 to use the old / wrong manglings for array-to-pointer decay for compatibility.

Also, this is probably obvious, but in the context of #166 the rule here should use precise typing when we mangle a substituted template argument as part of an expression.

[bolshakov-a]

The first example in this issue (a partially-substituted pack) is still not handled.

Thanks for explanation! I think it is irrelevant for that changes because they deal with single parameters, not with parameter packs.

See #47 / #166. adL_Z3arrE is not a correct mangling for an array-to-pointer decay.

I just mean: shouldn't the mangling be
_ZN1AIXadsoiL_Z3arrEEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE rather than
_ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE?

[zygoloid]

I just mean: shouldn't the mangling be _ZN1AIXadsoiL_Z3arrEEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE rather than _ZN1AIXadL_Z3arrEEE1fIPiEEvDTcvT_adsoiL_Z3arrEEE?

Oh, right. In #166 (comment) I suggested that we should avoid the adso mangling here when not using a precise type, which would give the result I said there. But I think we could go either way on that.