Additional mangled encodings for variadic templates

[Mike Herrick]

It appears that there are a few missing encodings in the IA-64 ABI document having to do with variadic templates and function parameters.

Take for example:

  template<class T, class... U> auto f1(T x, U... y) -> decltype(sizeof...(y),x);
  int main() {
    f1(0, 'c');
  }

The only option to encode a sizeof...() expression is:

  <expression> ::= sZ <template-param>         # size of a parameter pack

but the argument to sizeof...() in f1 above is a function parameter, not a template parameter.  Similarly, in this example:

  template<class... T> void f(T... t);
  template<class T, class... U> auto f2(T x, U... y) -> decltype(f(y...),x);
  int main() {
    f2(0, 'c');
  }

there appears to be no encoding for the function parameter pack expansion (i.e., y...) in this context; the only pack expansion is in <template-arg>:

  <template-arg> ::= sp <expression>           # pack expansion (C++0x)

but y... is used in an <expression> context.

I think adding these two productions to <expression> will address these problems:

                 ::= sZ <function-param>       # size of a function parameter pack
                 ::= sp <expression>           # expression pattern expansion

g++ 4.5.1 seems to already be using the second of these; the "sZ" mangling doesn't appear to be implemented in g++ as yet.

We'd also like to propose removing this production:

  <template-arg> ::= sp <expression>           # pack expansion (C++0x)

from the existing grammar.  If needed, this can be mangled with the existing rule (and the newly proposed rule above):

                 ::= X <expression> E          # expression

Keeping the existing rule as it is eliminates any future use of "p" as a single-letter <type> code (since <template-arg> can also be a <type> and "s" is already a valid <type> encoding).  Currently "p" is one of the few single-letter <type> codes not in use.  We realize this may not be practical due to backward compatibility issues.

Is there any other implementation experience for these cases?

Mike.