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

[John McCall]

On Jan 27, 2014, at 3:22 PM, Richard Smith <richardsmith at google.com> wrote:
> On 27 January 2014 15:08, John McCall <rjmccall at apple.com> wrote:
> On Jan 27, 2014, at 12:26 PM, Richard Smith <richardsmith 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.
>> 
>> This is jargon for the proposed constraints feature, not for enable_if.
>> 
>> We do not need to mangle enable_if conditions on class template patterns because of the ODR (and related rules in the templates chapter).
>> 
>> We don't even support enable_if conditions on class templates (+ specializations of them).
> 
> Any particular reason?
> 
> This is a feature for guiding overload resolution, not for anything directly template-related. We'd need to invent different semantics for it if we wanted to support it on class templates and partial specializations.

Okay.

> If you’ve got partial-ordering rules already, it seems like a very nice way to significantly improve the expressiveness of class template partial specialization.  Right now, users who want to specialize a template on e.g. POD types have to factor that into the original template signature.
> 
>> 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.
>> 
>> It's more complex than that. enable_if can look at the values of function arguments at a call site (if they are constant expressions), not just at template arguments, so we need to mangle it into the signature for all functions and function templates, even in the single-TU case.
> 
> What a majestic way of adding complexity without really making a significant improvement to expressiveness.  Why not instead add a feature to generally infer a non-type template parameter from a constant argument?
> 
> Primarily because it is intended to work in C as well as C++.

Ah, yes, I keep forgetting that, sorry.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140127/df420ba7/attachment-0001.html>