[cfe-dev] Clang-cl.exe and the VC++ preprocessor

[Alp Toker]

On 12/07/2014 12:10, Daniel James wrote:
> On 12 July 2014 03:22, Zachary Turner <zturner at google.com> wrote:
>> On Fri, Jul 11, 2014 at 1:52 PM, Alp Toker <alp at nuanti.com> wrote:
>>>
>>> The only hangup would be uncertainty around the interface to enable it
>>> (pragmas, what syntax? filename regex?) and maintainability. It's the kind
>>> of feature that's easy to implement, but burdensome to keep tested and
>>> stable, especially since we have no automated MSVC header integration tests.
>>
>> Something similar to how #pragma pack works sounds useful here.
>>
>> #pragma msvc_pp_compat(push)
>> #pragma msvc_pp_compat(on)
>>
>> ...
>>
>> #pragma msvc_pp_compat(pop)
> When a macro is defined at a point where compatibility mode is off,
> but expanded at a point where it's on, which mode would it use?

Nobody's tried to implement such a MSVC+standards mode precisely because 
we don't know the answers to those questions.


> Incidentally, is it likely that further compatibility changes will be
> made? My brief testing suggests that clang-cl

This is cfe-dev so it's worth being clear about the component in 
question: The MSVC mode is enabled by -fms-compatibility aka. 
MSVCCompat, and that determines the level of standards compliance, not 
the driver.

(The clang-cl driver basically just translates Microsoft-style 
command-line arguments, and happens to pass -fms-compatibility so it's 
just UI and tangential to the topic at hand.)

> is currently closer to a
> standards-compliant preprocessor than Visual C++'s preprocessor.
MSVCCompat is always going to tend *towards* Microsoft quirks. Retaining 
some standards compliance is secondary to the overriding goal of getting 
the long tail of Windows code out there to build. (That's an 
over-simplification -- there's actually a big effort to educate and 
diagnose non-compliant feature usage, but it doesn't do what you want.)

For example just this week there are patches in review to remove move 
standard PP definitions when the mode is enabled for example. So yes, so 
if you see this as a problem rather than a feature it's only going to 
get worse as compatibility improves.

It sounds like the request in this thread boils down to extending 
MSVCCompat to support more standards-compliance outside of system 
headers. In other words, parsing Microsoft headers and retaining VC++ 
ABI but not imposing those quirks on user code:

We already try to do a lot of that on the semantic analysis level, a few 
sporadic attempts in the parser, but AFAIK not yet any attempt to do so 
in the preprocessor.

So if you or other interested users could stump up some simple 
standalone test cases and write up desired semantics, I think we'd be 
happy to look into it, especially if it's not an open-ended proposal but 
rather a pinpoint precision operation to tighten up specific PP quirks.

Alp.

-- 
http://www.nuanti.com
the browser experts