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

[Nick Lewycky]

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

I thought you had asked me to invent a mangling for concept lite, then I
would use that plus a vendor extension node somewhere in the expression to
indicate that what I really had was a vendor extension.

What *did* you mean? Sorry for the protracted discussion.

Nick

We do not need to mangle enable_if conditions on class template patterns
> because of the ODR (and related rules in the templates chapter).
>

enable_if has to be mangled for a function template because it’s part of
> the template signature.  You can have two function template declarations in
> the scope scope with the same name and with identical template parameter
> signatures and type signatures, but if they have different enable_if
> conditions, then they’re considered different templates.  In typical use,
> this isn’t actually important: two overlapping function templates are
> probably defined in the same header file, and it’s likely that every call
> site will see both of them, and so any given list of template arguments
> that doesn’t lead to an ambiguity will probably pick the same template
> every time.  But that’s not actually *required*: it’s totally fine to have
> two different function templates in two different translation units that
> both accept the same template arguments, and we need to distinguish them.
>
> But two class temploids with the same name in the same scope always
> declare the same entity for the ODR’s purposes, and if a particular list of
> template arguments would pick an explicit specialization
> ([temp.expl.spec]p6) or partial specialization ([temp.class.spec]p1), that
> specialization is required to be defined in every translation unit that
> would use it.  So while you can guard a template pattern with an enable_if
> clause, it just controls whether that pattern is selected for
> instantiation, and the decision to select that pattern doesn’t need to be
> mangled in for the same basic reason that we don’t have to mangle in the
> partial-specialization signature we choose: ultimately, you can never
> legally simultaneously instantiate foo<int,char*> from two different
> patterns.
>
> Now, there are concepts proposals that interfere with this along multiple
> axes.  There are proposals which allow you to explicitly choose between
> ambiguous concept maps for a template argument, and there are proposals
> which allow you to define types in a concept map that would otherwise
> conflict in name with each other.  Both proposals affect mangling: the
> former suggests that we need to mangle a reference to the concept map as
> part of the template arguments, and the latter suggests that we need to
> mangle the concept map as part of the context.  But in neither case does a
> random expression in the <encoding> help.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140127/a049768b/attachment.html>