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

[Mike Herrick]

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)?

Thanks,

Mike Herrick
Edison Design Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20130807/7101242a/attachment.html>