Additional mangled encodings for variadic templates

[Mike Herrick]

On Nov 30, 2010, at 5:20 PM, Mike Herrick wrote:

> 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?

Here's the diff for the proposed changes above:

*** abi.orig.html       Wed Dec  8 14:26:04 2010
--- abi.html    Wed Dec  8 14:29:12 2010
***************
*** 4600,4606 ****
                   ::= X <expression> E                                   # expression
                   ::= <expr-primary>                                     # simple expressions
                   ::= I <template-arg>* E                                # argument pack
-                  ::= sp <expression>                                    # pack expansion (C++0x)
  
    <expression> ::= <<i>unary</i> operator-name> <expression>
                 ::= <<i>binary</i> operator-name> <expression> <expression>
--- 4600,4605 ----
***************
*** 4630,4635 ****
--- 4629,4636 ----
                 ::= pt <expression> <unresolved-name>                    # expr->name
                 ::= ds <expression> <expression>                         # expr.*expr
                 ::= sZ <template-param>                                  # size of a parameter pack
+                ::= sZ <function-param>                                  # size of a function parameter pack
+                ::= sp <expression>                                      # pack expansion
                 ::= tw <expression>                                      # throw expression
                 ::= tr                                                   # throw with no operand (rethrow)
                 ::= <unresolved-name>                                    # f(p), N::f(p), ::f(p),

Are there any objections to removing the "sp" mangling from <template-arg> from vendors who might already have implemented this scheme?

Mike.