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.
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.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
