[cxx-abi-dev] Mangling sizeof

[Doug Gregor]

On Fri, Mar 6, 2009 at 2:34 PM, Jason Merrill <jason at redhat.com> wrote:
> 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?

Sure.

> * 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.

That seems reasonable to me.

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

14.8.2p8 (in n2800) makes it pretty clear that any expression can
cause a substitution failure; the list of bullets is just a note, now.

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

... and they will, if only as a metaprogramming trick to determine
whether there is a "new" operator for the type.

> * delete
> * throw
>
> These seem even less likely.

Same here.

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

Yes, it does. I suggest that we consider all lambda expressions with
the same parameter type lists and return type (if provided) to be
"functionally equivalent". That way, we need only mangle the lambda's
call signature and not its body.

And, although it doesn't have any direct impact on the ABI, I think we
also need to say that failures substituting into the body of a lambda
are not substitution failures.

  - Doug