[cxx-abi-dev] Mangling sizeof

[Jason Merrill]

Jason Merrill wrote:
> Given that, the main thing that type stubs save us from needing to 
> represent is new expressions, which cannot appear in a constant 
> expression; other than that, they just save space in the mangled name.

Expressions that still lack manglings:

* alignof (type or expression)

We definitely need to mangle alignof, and that's simple: just add 
alignof operator names.  How about "at" and "az" to be parallel to the 
sizeof codes?

* functional cast with other than 1 argument

We definitely need to mangle functional casts with != 1 argument; this 
need has been there for a while.  Since we already have a mangling for 
the single argument, we need to leave that alone (though there is a 
disagreement in existing practice).  So either we need a different 
operator name than "cv", or we need an introducer for the list of 
expressions.  We can't use 'I', because that would be ambiguous; it 
could also be introducing the template args for the type of the 
conversion.  I'm currently wrapping the list of arguments in '_'/'E', 
but am in no way attached to that.

* Separate cast forms

Currently EDG and g++ mangle static_cast, const_cast, C cast and 
functional cast the same (cv type expr), and g++ doesn't support 
mangling reinterpret_cast or dynamic_cast.  EDG also mangles 
reinterpret_cast the same, and gets a substitution failure for dynamic_cast.

The distinction between different cast varieties definitely affects the 
validity of an expression, but it's not clear whether or not it can 
cause a substitution failure.  It might fall under

  - Attempting to perform an invalid conversion in either a template 
argument expression, or an expression used in the function declaration.

or not.  If not, there's no need for a distinct mangling.

* new

I'm not sure why someone would want to write decltype/sizeof(new T) 
rather than T*, but they could.

* delete
* throw

These seem even less likely.

And finally,
* lambda

Completely mangling lamba expressions in sizeof/decltype/alignof would 
mean having to mangle arbitrary statements as well, which seems rather a 
bridge too far.

Jason