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 > <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > <clang-lfun.patch> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
