Hi, On Mon, Jun 11, 2012 at 6:07 PM, Aaron Wishnick <[email protected]>wrote:
> Sorry to spam, but I sent this out a few days ago and there was no > response, and I'm wondering if it got filtered out due to the attachment. > It arrived, but many of the regular contributors are quite busy at the moment (and generally) so patches sometimes take a while to get reviewed. Common practice is to reply to your original message with "Ping." or similar, after about a week of no comments. > 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. > Do we need __LPREFIX() support for anything else? If not, it would seem a lot simpler to add support for a L__FUNCTION__, which behaves just like __FUNCTION__ but produces a wide string.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
