[cfe-dev] clang::LangOption policy

Thu Oct 15 03:08:17 PDT 2015

On Thu, Oct 15, 2015 at 12:59 AM, Joshua Gerrard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>
> There is a flag, MSVCCompat, which as you probably know already, tweaks
> some things so that clang works better on Windows.
>
> 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.
>
> 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.
>

I see our MSVC compatibility story a little differently.  We offer a
multitude of flags which control different aspects of compatibility with
MSVC:
-fms-extensions
-fms-compatibility
-fdelayed-template-parsing
-fms-compatibility-version/-fmsc-version
-fthreadsafe-statics
-relaxed-aliasing
/vd0, /vd1, /vd2
/vmg, /vmb, /vms, /vmv, /vmm
...

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.

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.

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.

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.

>
> 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?
>

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).

>
> How do you folks feel about this? I'd really like to make this my first
> contribution to clang.
>
> --
> Joshua Gerrard
> JUCE Software Developer
>
> *ROLI’s **award-winning*
> <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard
> GRAND, celebrated as the “**piano of the future*
> <http://edition.cnn.com/2013/09/27/tech/innovation/hans-zimmer-seaboard-future-piano/>*”,
> is now joined by the **Seaboard RISE*
> <https://www.youtube.com/watch?v=fGr7VbDiRNw>*, “**every bit as slimline
> and attractive as its bigger brother*
> <http://www.soundonsound.com/news?NewsID=18726>*”. The press is hailing
> the Seaboard RISE as “**innovative*
> <http://www.wired.co.uk/news/archive/2015-09/10/seaboard-rise-digital-keyboard-launch-uk-price>*”,
> “**expressive*
> <http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/>*”,
> “**accessible*
> <http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/>*”,
> and “**a keyboard controller that does to piano keys what 3D touch does
> to the iPhone*
> <http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/>*”.
> Now available for preorder at **www.roli.com* <http://www.roli.com/>*.*
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151015/0c08195b/attachment.html>