On 4/16/2016 12:58 AM, degski wrote:
On 16 April 2016 at 01:15, Edward Diener
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.