[PATCH] [ms-cxxabi] Mangle nullptr template arguments

David Majnemer david.majnemer at gmail.com
Mon Aug 5 00:08:24 PDT 2013

On Sun, Aug 4, 2013 at 11:41 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Sun, Aug 4, 2013 at 9:58 PM, David Majnemer <david.majnemer at gmail.com>wrote:
>> ================
>> Comment at: lib/AST/MicrosoftMangle.cpp:894
>> @@ +893,3 @@
>> +  case TemplateArgument::NullPtr: {
>> +    mangleIntegerLiteral(llvm::APSInt(/*BitWidth=*/64),
>> /*IsBoolean=*/false);
>> +    break;
>> ----------------
>> Richard Smith wrote:
>> > Sending nullptr_t through the integer literal codepath seems
>> unnecessary. All we really know here is that nullptr_t appears to be
>> mangled as A@, so maybe just emit that directly.
>> While we could do that, I think it makes the mangling scheme a bit more
>> complicated semantically and it decentralizes the mechanism of choosing how
>> to mangle zero-ish things.
>> As an example: bool template arguments. True and false aren't given
>> special mangling behavior. We "boolify" the integral value, treat the
>> result as an integer and mangle **that** value.
> That makes sense for bool, because it's an integer type, but there's
> nothing really integery about nullptr. Plus the "64" here is
> eyebrow-raising and ultimately irrelevant. (For Itanium, a null pointer
> also happens to be mangled exactly as if it were an integer literal with
> value 0 of the pointer type, but we have code to directly emit the mangling
> there too.)

I find the argument behind nullptr's non-integralness sufficient to change
direction, I've updated D1284.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/654d48e5/attachment.html>

More information about the cfe-commits mailing list