On Jan 21, 2014, at 2:01 PM, Richard Smith <[email protected]> wrote:
> On 21 January 2014 09:36, John McCall <[email protected]> wrote:
> On Jan 20, 2014, at 6:13 PM, Nick Lewycky <[email protected]> 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.
That’s a bit more future-proof, I suppose, although I think it might stretch
the definition of a type-qualifier to embed anything other than a value, and
value pack-expansions are already part of the <expression> grammar. You’re
really asking for a “allow an arbitrarily complex type to be manufactured here”
mangling.
> 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.
Unless the feature is likely to diverge so much that it won’t even be an
expression anymore, I don’t think this poses any problem for the ABI.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
