Hi,<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 6:07 PM, Aaron Wishnick <span dir="ltr"><<a href="mailto:aaron.s.wishnick@gmail.com" target="_blank">aaron.s.wishnick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div>
<div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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:</div>
<div><br></div><div>#define _STR2WSTR(s) L##s</div><div>#define STR2WSTR(s) _STR2WSTR(s)</div><div>#define __FUNCTIONW__ STR2WSTR(__FUNCTION__)</div><div><br></div><div>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: </div>
<div>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.</div>
<div>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.</div>
<div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
</div>