[cfe-dev] Setting default dialect to C++11

[Mehdi Amini via cfe-dev]

> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: cfe-dev at lists.llvm.org
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>> 
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
>>> Right, I don’t think it is a good idea for clang as a project to have
>>> important default configuration flags that diverge between
>>> platform/target, like the default language. This is reducing portability
>>> and quite user hostile IMO.
> 
> I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


> to have our toolchain default
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


> We provide the correct target triple; we point to the correct directory
> for our headers; we point to the correct directory for our libraries; we
> set the correct target and subtarget [there is only one]; we do a variety
> of other defaulting, as a service and convenience to our users.
> 
>> 
>> I somewhat disagree and that's why I didn't have a problem with the
>> change. As long as we silently miscompile C++03 code when enabling C++11
>> or later, I don't think it should be a general default. In a somewhat
>> more restricted environment like the Playstation toolchain, they are in
>> a much better position to judge wether those miscompiles will be
>> triggered by their userbase or not.
>> 
>> Joerg
>> 
>>> For example if a platform does not support exception, the driver can
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
> 
> We *support* exceptions, it's just not our *default* (same as for Xcode).
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
> is the burden you are proposing on all of our licensees.

I don’t see any burden here. 

> 
> Now let's look at it from the other side:  What are the advantages of having
> different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.


> Internally we run lots of our tests in a pile of different configurations
> (different optimization levels, with/without -g, with/without LTO, etc)
> and this has proven to be very helpful in finding bugs.
> 
> I don't have statistics off the top of my head but the C++11 default has
> found things; see for example PR32066.  This tells me there is value to
> avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.

— 
Mehdi