On Jan 27, 2014, at 3:41 PM, Nick Lewycky <[email protected]> wrote:
> On 27 January 2014 15:27, John McCall <[email protected]> wrote:
> On Jan 27, 2014, at 3:22 PM, Richard Smith <[email protected]> wrote:
>> On 27 January 2014 15:08, John McCall <[email protected]> wrote:
>> On Jan 27, 2014, at 12:26 PM, Richard Smith <[email protected]> wrote:
>>> On 27 January 2014 11:57, John McCall <[email protected]> wrote:
>>> On Jan 24, 2014, at 7:30 PM, Nick Lewycky <[email protected]> wrote:
>>>> On 24 January 2014 17:54, John McCall <[email protected]> wrote:
>>>> On Jan 24, 2014, at 5:36 PM, Nick Lewycky <[email protected]> wrote:
>>>>> On 23 January 2014 11:52, John McCall <[email protected]> wrote:
>>>>> 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.
>>>>>
>>>>> 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.
>
> Going back to adding a proposal for mangling attribute enable_if without
> concerning ourselves with concepts, I initially proposed:
>
> <type> ::= Ue <expression> E # vendor extended type qualifier
>
> which you corrected to:
>
> <type> ::= Ue <source-name> <expression> E <type>
>
> Richard dislikes this because we may be painting ourselves into a corner --
> what about the next vendor expression that takes two expressions and a type?
> -- and suggests this:
>
> <type> ::= U <source-name> <template-args> <type>
>
> which captures the full generality of things we might want to mangle. I
> dislike the use of template-args to name something that isn't template
> arguments, but that's an issue of naming only, and I don't have a better name
> to offer.
>
> Finally, you suggested putting it on <encoding> which would make it one of:
>
> <encoding> ::= <function name> <bare-function-type> [Ue <template-args>]
> or
> <encoding> ::= <function name> <bare-function-type> [Ue <expression>]
> ?
It should be at least partially center-embedded; adding optional elements at
the end of a mangling is a problem for demangling tools. There are places
where we do it already, but let’s avoid adding more.
> I'm leaning towards the fully general form of:
>
> <type> ::= U <source-name> <template-args> <type>
>
> What do you think?
Your <template-args> here can — and, as I understand it, are expected to —
contain references to function parameters that are actually introduced in the
nested <type>. This is not as a general of a notion as you two seem to think;
notably, no demangler is going to naturally handle your extension without
special-casing it. Just design something that works for your case.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
