[cfe-commits] [PATCH] Implement MS compatibility feature (bug 11789)

[Aaron Wishnick]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120609/b1e73ee6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lprefix.patch
Type: application/octet-stream
Size: 22810 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120609/b1e73ee6/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120609/b1e73ee6/attachment-0001.html>