This is my first contribution to this project, so please let me know if there's anything I can do to get this patch in better shape before committing. The aim of this patch is to fix an obstacle for clang working as a drop-in replacement for Microsoft's C++ compiler. A summary of this behavior is below, but it can also be seen in bug 11789: http://llvm.org/bugs/show_bug.cgi?id=11789

This patch adds a feature that is enabled only when "-fms-extensions" is set, to fix some errors trying to parse Microsoft's standard library implementation. In Microsoft's <locale> header, there is some debugging code that attempts to take the __FUNCTION__ predefined _expression_, and turn it into a wide char literal. It does something like this:

#define _STR2WSTR(s) L##s
#define STR2WSTR(s) _STR2WSTR(s)
#define __FUNCTIONW__ STR2WSTR(__FUNCTION__)

This wouldn't work in clang, because __FUNCTION__ isn't a macro, it's a predefined _expression_, so the token-paste operator just turns it into L__FUNCTION__, as the standard says it should. Microsoft's compiler has an undocumented extension that allows this to work, making it appear as if __FUNCTION__ were a macro, though it's not: 
1. The preprocessor special-cases pasting the token 'L' with __FUNCTION__, if __FUNCTION__ came from a macro expansion, pasting it to __LPREFIX( __FUNCTION__). This can be seen by using VC's preprocessor. When I say, "if __FUNCTION__ came from a macro expansion", I mean that _STR2WSTR(__FUNCTION__) does not have any special rules applied to it, in other words, the preprocessor pretends that __FUNCTION__ is a macro being expanded to a string, even though it's not.
2. The frontend is extended to parse __LPREFIX in a special way: The argument to __LPREFIX must be a compile-time constant string literal, or a predefined _expression_, and it must be formatted in UTF8. The result of the __LPREFIX _expression_ is the same string, but formatted as a wide char literal.

This patch implements both of these phases, and allows Microsoft's <locale> header to be successfully parsed. Please let me know if there's anything I can do to better package it. I developed it against the 3.1 release tag, but it applies cleanly to top of tree clang as well.

Best regards,
Aaron

Attachment: lprefix.patch
Description: Binary data

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to