[cxx-abi-dev] Literal operator functions with 'li<length, ID>'

[Richard Smith]

On Wed, Aug 7, 2013 at 11:49 AM, Mike Herrick <mjh at edg.com> wrote:

>
> On Jul 9, 2013, at 4:25 PM, Richard Smith <richardsmith at google.com> wrote:
>
> On Tue, Jul 9, 2013 at 11:12 AM, Mike Herrick <mjh at edg.com> wrote:
>
>> Hi,
>>
>> It appears that this patch for user-defined literals hasn't been applied
>> to the document (though it is used by at least g++ and clang).
>>
>> On Jun 5, 2011, at 4:11 AM, Sean Hunt <scshunt at csclub.uwaterloo.ca>
>> wrote:
>>
>> > Hi,
>> >
>> > I don't know where to find the document to patch against, but I'd like
>> to suggest that the line
>> >
>> >                 ::= li <source-name>  # "" <source-name>
>> >
>> > be added somewhere amongst the productions for <operator-name> in 5.1.3
>> since it's not yet in the document.
>>
>> Additionally, how about a case like this:
>>
>> int operator "" _w(const char*);
>> template <class T> auto f(T p1) -> decltype(123_w, p1);
>> int main() {
>>   f(456_w);
>> }
>>
>> Clang gives a mangling of _Z1fIiEDTcmclL_Zli2_wPKcELA4_cEEfp_ET_, but g++
>> aborts on this case.  I don't believe I've seen a discussion of this.
>
>
> Modeling a UDL as a call to the corresponding literal operator is an
> accident of Clang's implementation rather than a deliberate choice of
> mangling, but it seems reasonable to me.
>
>
> One follow-up related to the example that is given above; our UDL mangling
> produces a slightly different mangled name for this
> example: _Z1fIiEDTcmclL_Zli2_wPKcELA4_S0_EEfp_ET_, reflecting a difference
> in the cv-qualification of the type of the argument that is being passed to
> the literal operator.  Clang's demangled name reflects the use of "char
> [4]" as the argument type and we're using "const char [4]":
>
> < decltype(((operator "" _w((char [4])"..."),param#1))) f<int>(T1)
> ---
> > decltype(((operator "" _w((const char [4])"..."),param#1))) f<int>(T1)
>
> From a Standards point-of-view, we think "const char [4]" is correct here
> (the call to a raw literal operator X is defined to be equivalent to
> operator "" X("n"), and the type of "n" is "array of const char").  Is this
> a clang bug or the result of some implicit conversion (and if so, should it
> be reflected in the mangling)?
>

It looks like this was a transient bug -- I agree that your mangling is the
correct one, and it's also the one that Clang trunk produces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20130807/1c379179/attachment.html>