This is an archive of the discontinued LLVM Phabricator instance.

Support Unicode Microsoft predefined macros
AbandonedPublic

Authored by RIscRIpt on Aug 11 2023, 11:56 AM.

Diff Detail

Event Timeline

RIscRIpt created this revision.Aug 11 2023, 11:56 AM
Herald added a reviewer: njames93. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
RIscRIpt requested review of this revision.Aug 11 2023, 11:56 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 11 2023, 11:56 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

This implementation preserves support for identifiers L__FUNCSIG__ and L__FUNCTION__ (which have never been supported by MSVC), and adds other identifiers for all supported encodings: L, u8, u, U.

If breaking backwards compatibility in clang (with Microsoft Extensions) is allowed, then I'd prefer other (more correct) solution: support for __LPREFIX-family macros ( see https://godbolt.org/z/eacYqh1ab ), and remove token/identifiers like L__FUNCTION__; relevant issue https://github.com/llvm/llvm-project/issues/27402
I'll try to implement this alternative approach.

This does not appear to be valid under MSVC and I don't think we should support features that MS does not (Nor can i find any documentation that it ought to work)
https://godbolt.org/z/7Te3YYeb9

Supporting the same concatenation behavior MSVC does have seem like a cleaner approach. We would not have an many new tokens.
Before you do anything though. I'd like the feedback of more folks.

I can't find any documentation for LPREFIX, but it seems in the general case, it can be emulated that way https://godbolt.org/z/dr7MjMs99

In terms of breaking change, it's only an issue if L/u/etc are existing macro at the point of use.

cor3ntin removed a project: Restricted Project.
Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2023, 12:57 AM

This does not appear to be valid under MSVC and I don't think we should support features that MS does not (Nor can i find any documentation that it ought to work)
https://godbolt.org/z/7Te3YYeb9

Agreed -- we typically do not want to make extensions to Microsoft's extensions.

Supporting the same concatenation behavior MSVC does have seem like a cleaner approach. We would not have an many new tokens.
Before you do anything though. I'd like the feedback of more folks.

I can't find any documentation for LPREFIX, but it seems in the general case, it can be emulated that way https://godbolt.org/z/dr7MjMs99

In terms of breaking change, it's only an issue if L/u/etc are existing macro at the point of use.

It's a bit hard to reason about __LPREFIX given there's no documentation for it and it's not a macro that expands to anything we can poke at. However, https://github.com/llvm/llvm-project/issues/27402 shows there is interest in having Clang support it, so I weakly lean towards that option, though it may be more effort to reverse engineer how it works for various edge cases.

RIscRIpt planned changes to this revision.Aug 23 2023, 3:26 AM

While I work at __LPREFIX, I remove this revision from review queue.

RIscRIpt abandoned this revision.Aug 31 2023, 6:07 AM

I found a way to implement __LPREFIX-macros-family in Clang. I need some more time to finish and polish it. Going to post it a couple of weeks later.