[cxx-abi-dev] mangling of vendor extension, expression on function (not function type)

[Richard Smith]

On 21 January 2014 09:36, John McCall <rjmccall at apple.com> wrote:

> On Jan 20, 2014, at 6:13 PM, Nick Lewycky <nlewycky at google.com> wrote:
> > I'm trying to mangle a vendor extension that encodes an expression which
> applies to function overload candidates, with the goal that a user running
> the demangler would see their expression demangled. While there are various
> vendor extension points, none of them allow me to go into encoding an
> expression, unless I stick a stray "decltype" in there, or similar
> (expression in a template argument that doesn't actually exist, etc.).
> >
> > The vendor extension is described in full here:
> http://clang.llvm.org/docs/LanguageExtensions.html#controlling-overload-resolution.
> >
> > I don't think I can do it without an extension to the mangling rules. As
> a strawman proposal, I suggest this:
> >
> > <type> ::= Ue <expression> E # vendor extended type qualifier
>
> I think you mean
>
>   <type> ::= Ue <source-name> <expression> E <type>
>
> And this would be valuable for mangling e.g. dependent address space
> qualifiers, if anybody ever wants to do those.
>

We could generalize this slightly to

  <type> ::= U <source-name> <template-args> <type>

to allow multiple arguments (as types or expressions), dependent pack
expansions, and so on.

However, it feels really forced to add your feature, specifically, to
> <type>, since it can’t appear in an arbitrary position; it’s much closer to
> a qualified method name.  But the ref/cv-qualifiers area is only allowed in
> a <nested-name>, and you need to be able to do this on a top-level
> function, so I suppose extending <type> in a known-useful direction and
> then abusing <type> might be the best thing.
>
> On the other hand, isn’t this a proposed direction for standardization?  I
> would have no problem with giving this a proper, non-vendor mangling just
> in case.


It's not proposed for standardization with this syntax, and it's likely
that the final semantics will differ from the Clang extension in some ways
(the proposed partial ordering rules for constraints are rather more
complex, for instance), but it's close enough that it's an option worth
considering.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140121/4a66f949/attachment.html>