LGTM On 5 Aug 2013 00:08, "David Majnemer" <[email protected]> wrote:
> On Sun, Aug 4, 2013 at 11:41 PM, Richard Smith <[email protected]>wrote: > >> On Sun, Aug 4, 2013 at 9:58 PM, David Majnemer >> <[email protected]>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. > > Thanks >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
