Re: [boost] [clang] clang-cl expansion of macros

Subject: Re: [boost] [clang] clang-cl expansion of macros
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-04-16 10:58:51

On 4/16/2016 12:58 AM, degski wrote:
> On 16 April 2016 at 01:15, Edward Diener <eldiener_at_[hidden]> wrote:
>
> I have posted bug 27380 to the llvm/clang bug tracker...
>>
>
> Thanks for not giving up (also @ Niall D.)!

There's more. See bug 27382 at
https://llvm.org/bugs/show_bug.cgi?id=27382. And there is almost 
certainly more if the further errors from running the Boost PP tests are 
indicating other separate bugs. But I won't pursue further bug reports 
along those lines until I can ascertain whether or not fixing the ones 
that I have reported causes the remaining ones that appear when running 
the Boost PP tests to go away or not. And I haven't even started on 
clang-cl preprocessor bugs which the tests of VMD might reveal !

As I suspected the task of emulating the non-standard preprocessor 
behavior of VC++ is a daunting task and largely a fool's errand. If 
clang targeting VC++ had limited themselves to using their VC++ 
preprocessor emulation only for Windows headers and VC++ headers, while 
allowing all other header files to use their normal C++ standard 
conforming preprocessor, they would not have had to solve the emulation 
problem for all preprocessor macros. But they would not listen to reason 
concerning this.

What I strongly suspect will finally happen is that clang will not fix 
these emulation problems because they are too tricky and numerous to do. 
Instead they will probably declare that their emulation is good enough 
for the majority of preprocessor constructs and that Boost PP, which 
pushes the preprocessor to its limits, is not meant to work with their 
flawed VC++ emulation. I hope I am wrong about that supposition, but 
having spent much time in Boost PP and Boost VMD trying to workaround 
VC++ non-standard preprocessor behavior I can envision that having to 
code "down" to that behavior in numerous complicated instances will be 
too much time consuming work for the clang developers who have chosen to 
work with VC++ preprocessor emulation.