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

[Edward Diener]

On 7/12/2014 5:10 AM, 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?

The flag should be used to simply mark macro definitions which will 
either be expanded in the correct standard C++ preprocessor manner or in 
the compatible buggy VC++ preprocessor manner.

#pragma msvc_pp_compat(push)

#pragma msvc_pp_compat(on)

#define X whatever

#pragma msvc_pp_compat(off)

#define Y whatever

#pragma msvc_pp_compat(pop)

When the macro X gets expanded anywhere in code it uses the compatible 
buggy VC++ manner of macro expansion. When the macro Y gets expanded 
anywhere in code it gets expanded according to the C++ standard.

Surely that can be implemented. I do not care if VC++ compatibility is 
turned on by default in order to compile VC++ header files as long as 
the macro programmer can surround his own set of C++ standard macros 
with #pragma msvc_pp_compat(push) and #pragma msvc_pp_compat(off), and 
finally #pragma msvc_pp_compat(pop) at the end of his header file.

>
> Incidentally, is it likely that further compatibility changes will be
> made? My brief testing suggests that clang-cl is currently closer to a
> standards-compliant preprocessor than Visual C++'s preprocessor.

In testing Boost PP on 'develop', where I have added a slew of new 
tests, only the one situation I reported show a clang-cl error due to 
the VC++ emulation. However this does not mean that even more 
complicated uses of the preprocessor will not show problems in 
clang-cl's VC++ emulation. That is the main reason why I would like to 
strongly suggest the above, which would could insure standard C++  macro 
expansion in clang-cl for a macro library such as Boost PP even when 
clang-cl has to use VC++ emulation for Microsoft's own header files.