Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows

Subject: Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-04-05 06:51:32

On 4/5/2016 3:53 AM, Niall Douglas wrote:
> On 4 Apr 2016 at 16:21, Paul Mensonides wrote:
>
>> I am not referring to VC++.  I am referring to clang intentionally
>> conforming to VC++ rather than conforming to the Standard.  That
>> decision is crap and the mentality that produced it is also crap.  The
>> same is true for any other intentional nonconformance.
>
> Until very recently - VS2015 Update 2 - clang needed to behave like
> MSVC in order to grok Windows system headers.
>
> Now Windows system headers are (apparently) standards conforming,
> clang no longer needs to behave this way. Hence me submitting feature
> request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang
> no longer implement a broken preprocessor except in msvc
> compatibility mode.
>
> (Note as of Update 2, -fms-compatibility is no longer needed to use
> clang with a MSVC target. An enormous improvement).
>
>> What it says to me is either that clang's popularity is more important
>> to the clang project than clang doing the right thing (i.e. decisions
>> based on benefitting clang (popularity/adoption/etc.) not on benefitting
>> the C++ community) or that the clang project's technical decision-making
>> is extremely shortsighted--or both.
>
> I think their decision making here is far more driven by lack of
> resources than anything else, only a tiny - if very productive -
> segment of clang's dev team work on MSVC ABI support. They needed to
> sell to management the need for a MSVC ABI target. That means telling
> a very simple compelling use case story. As Microsoft have now picked
> up clang for Visual Studio and have finally repaired their headers,
> I'd call that simple story a resounding success.
>
>> This is about what clang is doing, not Microsoft.  Microsoft has
>> intentionally disregarded the Standard repeatedly over a long period of
>> time.
>
> The Microsoft compiler team had strong business reasons to do so.
> Their biggest customer is Microsoft itself, and parts of that org
> want a broken preprocessor and other deviations from the spec.
> Everyone I know in the compiler team would *just love* to conform to
> the standard more closely, but in the end your biggest customers
> drive the product.
>
>> They are getting better, slowly.  That's old news.  Clang,
>> however, has now made a decision to intentionally disregard the Standard
>> as well in order to attempt conform to Microsoft's definition of C++.
>> Microsoft lost my respect a long time ago and has yet to regain it.
>> Clang has now lost it as well.
>
> Microsoft decided to resource a clang port to Visual Studio some
> years ago. Gaby dos Reis indeed did much of the original prototyping
> of clang married to C2 codegen to see if it was viable. That's now a
> shipping product. Microsoft are tidying and fixing up the rest of the
> tool ecosystem to become as standards conforming as any other
> ecosystem, indeed some would argue that STL has been a bit *too*
> standards conforming in the MSVC STL in that he has exchanged
> performance in a number of places for a very strict interpretation.
>
> Whatever respect you have for whom is your business, but no one can
> argue that very significant resources have been directed at this over
> many years, and it is having big effects. There is every reason to
> expect that the MSVC ABI target will be 98% C++ *17* standards
> conforming by end of 2017. Most of the missing 2% are due to legacy
> ABI problems e.g. the MSVC mangling system can't easily express
> lambda types in template args etc. That's as good as is achievable on
> an ABI approaching thirty years old and long preceding ISO
> standardisation.
>
> Microsoft are also the only vendor shipping finished editions of many
> of the 17 era Library Fundamentals. VS2015 ships a very high quality
> implementation of the Filesystem TS for example, indeed it has fewer
> quirks than Beman's edition in Boost. I understand that is only going
> to improve in the next two years as Modules, Concepts and Coroutines
> all land, and by 2018 it is highly likely Microsoft's C++ dev
> environment will meet or exceed that of any other major vendor bar
> none.
>
> Like you, I'll believe that when I see it, but the trends are looking
> excellent. Microsoft is back to being competitive in C++ after a gap
> of over twenty years.

And when does Microsoft actually ship a version of VC++ with a C++ 
standard conforming preprocessor ?

Nobody is holding their breath for this just as nobody has held their 
breath for this over the last 25 years, during which Microsoft has 
repeatedly made noises that they will fix their non-standard conforming 
preprocessor and never have done so.

All this talk of yours about how conformant to the C++ standard 
Microsoft is becoming means nothing unless they can fix the 
preprocessor. The rest of your touting of how serious Microsoft is in 
conforming to the C++ standard is just "show business" to me. Whatever 
Microsoft ships as their backend compiler, whatever noises they make 
about being serious about conforming as closely as possible to the C++11 
or C++14 or C++17 standards, if they can't ship a C++ standards 
preprocessor they will never be conformant to the C++ standard.