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

[Nick Lewycky]

On 23 January 2014 11:52, John McCall <rjmccall at apple.com> wrote:

> On Jan 21, 2014, at 2:01 PM, Richard Smith <richardsmith at google.com>
> wrote:
>
> 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.
>>
> Yep, that's what I meant. Thanks!

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

Vendor hat on, I reserve the right to make my extension behave differently
from anything that's been standardized. As long as I can slip a vendor
extension particle into the mangled name I'll be happy to use otherwise
normal mangling. If it turns out I don't have to, all the better, but I'm
not banking on it.

Do you want me to try to prepare a patch for template constraints? I think
it would look similar to my strawman proposal, except that I'd pick some
other available letter?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140124/5aed61ae/attachment.html>