On Sun, Aug 4, 2013 at 9:58 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">================</div><div class="im">
Comment at: lib/AST/MicrosoftMangle.cpp:894<br>
@@ +893,3 @@<br>
</div><div class="im">+  case TemplateArgument::NullPtr: {<br>
+    mangleIntegerLiteral(llvm::APSInt(/*BitWidth=*/64), /*IsBoolean=*/false);<br>
+    break;<br>
</div>----------------<br>
<div class="im">Richard Smith wrote:<br>
> 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.<br>
</div>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.<br>
<br>
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.</blockquote><div><br>
</div><div>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.)</div>
</div>