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

[Daniel James]

On 12 July 2014 11:07, Alp Toker <alp at nuanti.com> wrote:
>
> 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.

It's hard to understand the consequences of such a change without
knowing. I expect mixing modes would be probably be trouble than it's
worth, so would use whatever the current mode is, but didn't want to
assume. I think that could be used in boost. It would be verbose, but
that's typical. Users would have to use these pragmas when using the
preprocessor library, but I expect most won't need to support this
use-case.

>> 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.)

Sure, I'm using clang-cl as short-hand, compiler flags don't trip of
the tongue. I'd just end up writing -fms-extensions when I mean
-fs-compatibility.

>> 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.)

I mainly want to understand what you're doing, and how this can be
dealt with in Boost.

> 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.

I don't think that example is much of a problem. But the big issue is
if the clang preprocessor is a moving target. If we could just get
boost running with whatever's in clang at the moment and say that
boost won't work with older versions of clang visual c++ emulation,
then that seems fine. I'd probably implement it if no one else is
willing. But if it that will then break with every new version of
clang, and we can only fix it with backwards-incompatible changes,
then that's a problem.

> 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.

If that's the best solution available, I guess it would work.
Personally, I always find a bit odd when the same code works
differently in different places for no obvious reason.

> 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.

Do you mean to get clang emulation to support the Visual C++
preprocessor code? I'll look into it.