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

[Aaron Wishnick]

Nico, thanks for doing this! This looks better to me for sure. The only thing is I think you may have forgotten to remove the __LPREFIX keyword from my patch: 

+KEYWORD(__LPREFIX                   , KEYMS)

Also it might make sense to completely remove Preprocessor/macro_paste_msextensions.cpp test, since there's no longer any special macro-pasting code.

On Jun 22, 2012, at 8:18 PM, Nico Weber wrote:

> 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
>> 
> <clang-lfun.patch>