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

[Richard Smith]

On 27 January 2014 14:56, John McCall <rjmccall at apple.com> wrote:

> On Jan 27, 2014, at 1:15 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
> On 27 January 2014 11:57, John McCall <rjmccall at apple.com> wrote:
>
>> On Jan 24, 2014, at 7:30 PM, Nick Lewycky <nlewycky at google.com> wrote:
>>
>> On 24 January 2014 17:54, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Jan 24, 2014, at 5:36 PM, Nick Lewycky <nlewycky at google.com> wrote:
>>>
>>> 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.
>>>
>>>
>>> I completely agree that this is acceptable vendor-hat behavior and that
>>> the fake-qualifier idea isn’t a bad approach for 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?
>>>
>>>
>>> Yes, except that grammatically you should make it part of the function
>>> <encoding> instead of adding it to <type>.  It works out to the same basic
>>> position.
>>>
>>
>> Okay, first attempt at a patch attached. Please review.
>>
>> A couple things. I chose 'Q', short for 'requires' to indicate a
>> constraint. I put the new part on all encodings, not just functions,
>> because you may need to mangle a static data member inside a class that has
>> a concept applied, and similarly for its vtable and special members.
>>
>>
>> I’m confused about what you mean by ‘concept’ here.  If it's just jargon
>> for the enable_if feature, it seems completely counterproductive.
>>
>
> Sorry, we had a miscommunication. I asked "Do you want me to try to
> prepare a patch for template constraints?" meaning template constraints as
> defined in N3701 (a.k.a, "concepts lite"), and you answered "Yes, except
> that grammatically you should make it part of the function <encoding>
> instead of adding it to <type>”.
>
>
> Ah.  Yes, I am not quite that embedded in committee minutiae.  I assumed
> you were talking about some proposal to standardize something closely
> pattern on this feature, which is, in fact, a way of declaring a constraint
> on a template.  It looks like N3701 is roughly similar but would require
> some additional work, e.g. to figure out the exact canonical way to turn
> the sugar forms (“Copyable T”) into requires clauses.
>
> I’m still not sure what in N3701 requires you to mangle constraints into
> class names.
>

I think your prior assertion that we would only need this mangling for
constraints on function templates is correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140127/fd0c4f38/attachment.html>