<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 10, 2014 at 2:25 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 7/10/2014 4:14 PM, Chandler Carruth wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
On Thu, Jul 10, 2014 at 12:55 PM, Edward Diener<br>
<<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.<u></u>com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@<u></u>tropicsoft.com</a>>> wrote:<br>
<br>
I have been told, via my bug report on a preprocessor error in the<br>
latest version of clang-cl.exe, that clang-cl.exe is trying to<br>
emulate at least some of the bugs of the VC++ preprocessor.<br>
<br>
NO ! Please do not do that.<br>
<br>
I know, from having worked on variadic macros in Boost PP and having<br>
created my own variadic macro data library, how broken the VC++<br>
preprocessor is when it comes to preprocessor metaprogramming. Paul<br>
Mensonides, the creator of Boost PP and an exceptional expert on the<br>
C++ preprocessor, also knows and has bemoaned countless times how<br>
difficult it is to do preprocessor metaprogramming if one has to<br>
deal with the VC++ preprocessor. Not only will clang-cl.exe's<br>
emulation of the brokeness of the VC++ preprocessor set back further<br>
efforts in metaprogramming preprocessor code and libraries but there<br>
is absolutely no chance, if it means anything to clang-cl<br>
developers, that any effort will be made to accomodate clang-cl's<br>
preprocessor bugs into Boost PP ( or my own variadic macro data<br>
library ).<br>
<br>
This is completely the wrong direction for clang-cl to go. Please<br>
stop and only consider producing as close to as possible a 100% C++<br>
conformant preprocessor, as the rest of clang no doubt has as its goal.<br>
<br>
<br>
So, I feel like we're between a rock and a hard place here.<br>
<br>
At a fundamental level there are bugs we need to be bug-for-bug<br>
compatible with because there is large amounts of existing code in the<br>
wild relying on those bugs.<br>
<br>
At the same time, I'm quite sympathetic to not wanting to make things<br>
less conforming.<br>
</div></div></blockquote>
<br>
In the case of the VC++ preprocessor you really have to be a masochist, and someone with little pride in correct C++, to want to emulate the bugs there.</blockquote><div><br></div><div>I don't have much of an opinion on this topic (as long as clang-cl can parse MS headers), but please drop the hyperbolic language and stick to technical arguments.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But I don't see an easy way to have both. Here are my suggestions, but<br>
none of them are great:<br>
<br>
1) Make sure that any bug-compatibility is inspired by actual code<br>
relying on the bug. I suspect it is in this case, but its always good to<br>
check.<br>
</blockquote>
<br></div>
This is a fool's errand, sir. You have no idea of all the "existing code in the wild". Do you really think because someone has written a macro that relies on the non-conformance of the VC++ preprocessor that it is clang-cl's responsibility to reproduce that same preprocessing bug ? Or even a theoretical someone.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) It may be desirable for Boost (and Boost users) to opt into a more<br>
strict mode. I get the flags backwards all the time (Reid or someone<br>
else will correct me) but we have two flags to control compatibility:<br>
one for essentially conforming (or at least not horrible broken)<br>
extensions, and another for bug-for-bug compatibility. I think the<br>
latter is '-fms-compatibility' while the former is '-fms-extensions',<br>
but again, i get them backwards. Anyways, perhaps Boost would want to<br>
use '-fno-ms-compatibility' where possible to get a more conforming<br>
implementation.<br>
</blockquote>
<br></div>
I do not ultimately control the Boost PP library, Paul Mensonides does although I am a contributor, but I can almost guarantee you that he has no inclination, and I know I have none, to make any changes to accomodate clang-cl's emulation of VC++ preprocessor bugs no matter what compatibility options and emulation of whatever VC++ preprocessor bugs clang-cl wants to promote. And if others are willing to go into that Boost PP code and hack around with it given the ridiculousness of clang-cl attempting to emulate the brokeness of the VC++ preprocessor in whatever respects, I wish them the best of luck through their hair-pulling and tears.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) I think we should then make sure we expose macros you can use to<br>
detect the bug-for-bug compat mode, and use the (horrible) cl.exe<br>
implementations of things like Boost PP, even though the host compiler<br>
is Clang.<br>
<br>
Does this make sense?<br>
</blockquote>
<br></div>
Not to me. The only thing that makes sense, quite honestly, is that clang, and clang-cl, produce a C++ standard conforming preprocessor. Furthermore there is no way you will ever get Microsoft to fix their broken preprocessor if you think that emulating their own preprocessing bugs is the way to go. If you want to make a switch in clang-cl to produce a standard conforming preprocessor, rather than have it be the default, my message to anyone using Boost will be simply that without this switch there is no point in using Boost in their code. Of course if this does not matter they can do what they want.<br>
<br>
Please, please reconsider the notion that you can produce a compiler worthy of clang, to be used by VC++ programmers, by reproducing VC++ preprocessor bugs. This is a realy bad path to take.<div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>