[cxx-abi-dev] N4198 and mangling for member pointer template arguments

[Richard Smith]

On 2 December 2014 at 18:47, John McCall <rjmccall at apple.com> wrote:

> On Dec 2, 2014, at 5:42 PM, Richard Smith <richardsmith at google.com> wrote:
>
> On 2 December 2014 at 16:34, John McCall <rjmccall at apple.com> wrote:
>
>> On Dec 2, 2014, at 3:51 PM, Richard Smith <richardsmith at google.com>
>> wrote:
>> On 2 December 2014 at 13:58, John McCall <rjmccall at apple.com> wrote:
>>>
>>> Hmm.  I’d prefer not to hard-code an order dependence, because I think
>>> it’s likely that the committee will eventually weaken the rules about where
>>> packs can appear in parameter lists (e.g. to allow templates to pull
>>> arguments off the end instead of the beginning).
>>>
>> So I think we either need to do what EDG does and heroically match later
>>> arguments which have to be part of the pack — which may or may not work
>>> equally well with future pack-placement rules — or pull back and say we’re
>>> completely blocked by the existence of dependent pack expansions.
>>>
>>
>> EDG's approach is impossible to follow in some cases, such as:
>>
>>   template<int A, short B, int C = 0> struct X {};
>>   template<int ...N> void f(X<N..., 5>) {}
>>   template void f<0>(X<0, 5>);
>>   template void f<0, 1>(X<0, 1, 5>);
>>
>> (EDG rejects this, which I suspect is related to their eager analysis of
>> template arguments.)
>>
>>
>> Okay.  So are we comfortable with a simple rule that dependent pack
>> expansions always make a template argument “dependent” in the sense I
>> described?
>>
>
> Is the suggestion that the entire template argument list becomes dependent
> if it contains a dependent pack expansion[1]? Or that template arguments at
> or after a dependent pack expansion become dependent? The latter is what
> everyone is currently doing; the former would be more future-proof but is
> an ABI break for all implementations I surveyed.
>
>
> I’m just trying to come up with a well-defined rule.  The current compiler
> behavior appears to be directly exposing implementation decisions about
> when to type-check template arguments against their parameters.  EDG’s
> efforts are well-intentioned and could certainly be followed without
> actually getting the case you described wrong; conversely, why should some
> amount of known-to-be-incomplete checking be required just to produce a
> correct mangling?  As far as I know, we generally don’t require any
> expressions in a function template signature to be type-checked except in
> specific circumstances which only apply if they’re
> instantiation-independent.
>
> A rule of “use type-checked template arguments only if you can type-check
> all the template arguments” makes the most sense to me, but it might be too
> compatibility-breaking.
>

I think that's a good direction to pursue. Do we have a good way of
measuring the actual impact of such changes?

There's also the question of whether we canonicalize the template
arguments. Consider:

  template<int, int> struct X {};
  template<int ...N> void f(X<N..., 1 + 1>);
  void h() { f<0>({}); }

Here, due to the pack expansion, GCC and Clang mangle the 1 + 1 template
argument as XplLi1ELi1EE. That's non-conforming; this expression doesn't
involve a template parameter, so

  template<int ...N> void f(X<N..., 2>) {}
  template void f<0>(X<0, 2>);

... in another TU is required to instantiate the same function template
specialization. I'm torn on whether this is a defect in the standard or
whether we should kowtow to this in the ABI.

> Here, GCC mangles f<A> and g<A> the same, even though one of them refers
>> to A as a class template, and the other refers to A as a non-template
>> injected-class-name. That might just be a GCC bug, though; its diagnostics
>> suggest that it thinks the template argument for f is A<int> rather than A.
>>
>>
>> Definitely seems like a GCC bug.  I hope Clang mangles the first as a
>> reference to A and the second as the type A<int>?
>>
>
> Clang does not implement injected-class-name template-argument duality, so
> it rejects.
>
>
> Ah, okay.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20141202/29df0706/attachment-0001.html>