<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 12:59 AM, Joshua Gerrard via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>So I've been working with clang as a library on Windows for a little while now, and I'm noticed a few things that I'd like to change, but in order to do so I need to know the "clang policy" for such things first.</div><div><br></div><div>There is a flag, MSVCCompat, which as you probably know already, tweaks some things so that clang works better on Windows.</div><div><br></div><div>However, other flags are required, such as DelayedTemplateParsing, in order for things to work. Now I understand that these need to be separate flags so that users on other platforms can enable things like DelayedTemplateParsing for other reasons, but as it stands enabling MSVCCompat doesn't make clang compatible with Windows.</div><div><br></div><div>As a result, I'd like to fix this problem by making things like DelayedTemplateParsing take effect when MSVCCompat is turned on. However, this would make it so that the "implied" flags would essentially have no effect, and turning off DelayedTemplateParsing would not have any effect if MSVCCompat was turned off.</div></div></blockquote><div><br></div><div>I see our MSVC compatibility story a little differently. We offer a multitude of flags which control different aspects of compatibility with MSVC:</div><div>-fms-extensions</div><div>-fms-compatibility</div><div>-fdelayed-template-parsing</div><div>-fms-compatibility-version/-fmsc-version</div><div>-fthreadsafe-statics</div><div>-relaxed-aliasing<br></div><div>/vd0, /vd1, /vd2</div><div>/vmg, /vmb, /vms, /vmv, /vmm</div><div>...</div><div><br></div><div>While many (all?) of these flags have some effect on language conformance, there are perhaps two which have no discernible ABI impact (outside of, say, SFINAE): -fms-compatibility and -fdelayed-template-parsing.</div><div><br></div><div>These two flags engage orthogonal pieces of our compatibility machinery and the intent is to ask users of clang to enable the bare minimum they need in the hopes that we would encourage authorship of code which is portable and free of reliance on compiler quirks. -fms-compatibility is less bad than -fdelayed-template-parsing in my eyes in that -fdelayed-template-parsing will result in ASTs which have way worse fidelity.</div><div><br></div><div>I think it is reasonable for tools like clang-cl to enable both flags by default due to it's fundamental nature but I don't think that's a decision we'd want to make for tools at large.</div><div><br></div><div>At a rather fundamental level the tool really needs to know whether or not it should run the frontend with /vd2 or /vmv, some information must be supplied to us. I would rather see tools actively make the decision to use -fdelayed-template-parsing instead of get opted into it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Furthermore, I can't see the point in having both a MSCompatibility flag and a MSVCCompat flag; surely we should have one or the other?</div></div></blockquote><div><br></div><div>I can't seem to find MSCompatibility as an identifier in clang's sources. However, I can find the similarly named MSCompatibilityVersion. MSCompatibilityVersion is intended to be useful outside of MSVCCompat: clang emitting MSVC-style diagnostics when targeting non-MSVC platforms is a not-uncommon thing; some versions of VisualStudio do the wrong thing and MSCompatibilityVersion lets us know if we should work around them (see Frontend/TextDiagnostic.cpp).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>How do you folks feel about this? I'd really like to make this my first contribution to clang.<br clear="all"></div><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><p dir="ltr">--<br> Joshua Gerrard<br> JUCE Software Developer<br></p><p dir="ltr"><font size="2"><i>ROLI’s </i><a href="http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html" target="_blank"><i><font color="#1155cc">award-winning</font></i></a><i> Seaboard GRAND, celebrated as the “</i><a href="http://edition.cnn.com/2013/09/27/tech/innovation/hans-zimmer-seaboard-future-piano/" target="_blank"><i><font color="#1155cc">piano of the future</font></i></a><i>”, is now joined by the </i><a href="https://www.youtube.com/watch?v=fGr7VbDiRNw" target="_blank"><i><font color="#1155cc">Seaboard RISE</font></i></a><i>, “</i><a href="http://www.soundonsound.com/news?NewsID=18726" target="_blank"><i><font color="#1155cc">every bit as slimline and attractive as its bigger brother</font></i></a><i>”. The press is hailing the Seaboard RISE as “</i><a href="http://www.wired.co.uk/news/archive/2015-09/10/seaboard-rise-digital-keyboard-launch-uk-price" target="_blank"><i><font color="#1155cc">innovative</font></i></a><i>”, “</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><font color="#1155cc">expressive</font></i></a><i>”, “</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><font color="#1155cc">accessible</font></i></a><i>”, and “</i><a href="http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/" target="_blank"><i><font color="#1155cc">a keyboard controller that does to piano keys what 3D touch does to the iPhone</font></i></a><i>”. Now available for preorder at </i><a href="http://www.roli.com/" target="_blank"><i><font color="#1155cc">www.roli.com</font></i></a><i>.</i></font><br><br></p></div></div></div></div></div></div></div></div></div></div>
</div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>