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

Nico Weber thakis at chromium.org
Fri Jun 22 17:18:05 PDT 2012


The attached patch changes Aaron's patch to just support
L__FUNCTION__. I'll deduplicate CopyStringFragment(). Is this
basically ok?

On Tue, Jun 12, 2012 at 7:25 AM, Aaron Wishnick
<aaron.s.wishnick at gmail.com> wrote:
> 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.
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-lfun.patch
Type: application/octet-stream
Size: 11256 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120622/0438b1c8/attachment.obj>


More information about the cfe-commits mailing list