[cfe-commits] Requesting review of MS compatibility patch (fixes bug 11789)

[Richard Smith]

Hi,

On Mon, Jun 11, 2012 at 6:07 PM, Aaron Wishnick
<aaron.s.wishnick at gmail.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120611/0b832d47/attachment.html>