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? 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?
Oh well, I am not designing your language feature. I acknowledge that you also
need to mangle this into non-template functions. I don’t understand why you
care about mangling it into class names.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
