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.
Also, it's not clear to me whether constraints are ordered, and I make no
attempt to specify this in the ABI.
Nick
diff --git a/abi.html b/abi.html
index 84eb3fb..91e8480 100644
--- a/abi.html
+++ b/abi.html
@@ -4016,18 +4016,19 @@ Entities with C linkage and global namespace variables are not mangled.
Mangled names have the general structure:
<pre><font color=blue><code>
<<a name="mangle.mangled-name">mangled-name</a>> ::= _Z <<a href="#mangle.encoding">encoding</a>>
- <<a name="mangle.encoding">encoding</a>> ::= <<i>function</i> <a href="#mangle.name">name</a>> <<a href="#mangle.bare-function-type">bare-function-type</a>>
- ::= <<i>data</i> <a href="#mangle.name">name</a>>
- ::= <<a href="#mangle.special-name">special-name</a>>
+ <<a name="mangle.encoding">encoding</a>> ::= <<i>function</i> <a href="#mangle.name">name</a>> [Q<<a href="#mangle.expression">expression</a>>] <<a href="#mangle.bare-function-type">bare-function-type</a>>
+ ::= <<i>data</i> <a href="#mangle.name">name</a>> [Q<<a href="#mangle.expression">expression</a>>]
+ ::= <<a href="#mangle.special-name">special-name</a>> [Q<<a href="#mangle.expression">expression</a>>]
</pre></font></code>
Thus, a name is mangled by prefixing "_Z" to an encoding of its name,
-and in the case of functions its type (to support overloading).
-At this top level,
-function types do not have the special delimiter characters required
-when nested (see below). Furthermore, in the case of instances (or
-explicit specializations) of function templates and member function
-templates (but not ordinary member functions of class templates), the
+its constraints from a requires clause if applicable, and in the case
+of functions its type (to support overloading).
+At this top level, function types do not have the special delimiter
+characters required when nested (see below). Furthermore, in the case
+of instances (or explicit specializations) of function templates and
+member function templates (but not ordinary member functions of class
+templates), the
<code><<a href="#mangle.bare-function-type">bare-function-type</a>></code> encoding is that of the type
expressed in the template (i.e., one likely involving template
parameters).
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
