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

[Aaron Wishnick]

I see what you're saying. I'll get together a patch that implements L__FUNCTION__ and a predefined __LPREFIX macro.

On Jun 12, 2012, at 1:04 AM, Richard Smith wrote:

> On Mon, Jun 11, 2012 at 6:31 PM, Aaron Wishnick <aaron.s.wishnick at gmail.com> wrote:
> On Jun 11, 2012, at 9:15 PM, Richard Smith wrote:
>> 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.
> 
> 
> MSVC also supports some other predefined expressions, like __FUNCDNAME__, __FUNCSIG__, etc, so it would be necessary to provide the wide versions of any of those.
> 
> OK, but we don't yet support any of those, and adding the L version at the same time would probably not be a massive undertaking.
>  
> Also, though it's undocumented, there are people who know about it and use it, e.g. see [1] and [2]. Also, my hope for this patch is to increase compatibility with the MSVC headers, as well as other projects that only target Microsoft's compiler, and there's the potential for those other projects to make use of the __LPREFIX extension.
> 
> If that's a problem in practice, we could provide a predefined __LPREFIX macro:
> 
> #define __LPREFIX_impl(x) L ## x
> #define __LPREFIX(x) __LPREFIX_impl(x)
>  
> I agree though, it would be much simpler to add L__FUNCTION__, so I guess it's up to you where you want to set the bar.
> 
> It certainly seems reasonable for us to provide compatibility with constructs which are used in MSVC headers, such as L ## __FUNCTION__. The argument for providing perfect compatibility (to handle situations we've not seen) is weaker.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120612/2df63577/attachment.html>