[cfe-dev] clang::LangOption policy

Thu Oct 15 03:35:16 PDT 2015

On Thu, Oct 15, 2015 at 3:24 AM, Joshua Gerrard <joshua.gerrard at roli.com>
wrote:

> Yes, I meant MSCompatibilityVersion (sorry about that).
>
> I see your point about having the granularity available to the user; users
> not want some tweaks whilst still wanting others.
> However, it feels like a misnomer having a flag MSVCCompat that doesn't
> enable everything needed to compile the Windows headers. Perhaps this is a
> naming issue.
>

I think you've hit the nail on the head, MSVCCompat is poorly named in our
big sea of compatibility options.

>
> Does clang-cl have a function I can call into to get the appropriate flags
> set (LangOptions and anything else that needs to be set)? If not, how would
> you feel about me adding one? I feel this would make developing an
> application that uses libclang for Windows easier, as you could simply
> point them to that function.
>

What might be useful is adding a dump method to LangOptions which would let
you examine how particular invocations of clang/clang-cl have it configured
under different flags.

>
> Thanks for your input!
>

Happy to help :)

>
> --
> 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/>*.*
>
>
> On 15 October 2015 at 11:08, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>>
>>
>> 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/40d056a4/attachment.html>