Is it about time to advance Clang's default C++ dialect to C++11?
It has been stuck on 98/03 for quite some time now.
Charles Li has been doing a lot of patient work for a long time to get
Clang's lit tests to be compatible with C++11. There are only 16 tests
that still need to be reviewed:
Once those are in, we should be able to update the default.
Even if it is not time to update the default for everyone, I would
*really* LOVE to set the default dialect for the PS4 target. That
would at least make sure there is no future back-sliding with regards
to future test changes, because our public PS4-target bots will catch
those cases. But, those last 16 tests need to be fixed up before we
can do that.
Anybody willing to give some LGTM on the tests, we'd be very grateful.
And any thoughts about upgrading the default for everyone, rather than
just for PS4, would also be welcome.
Generally I think this is overdue, and that we should go straight to C++14
rather than stopping at C++11 (like GCC did).
This policy makes sense. With GCC's change, projects must explicitly
specify a -std if they insist on a particular language standard and as such
changing Clang's default shouldn't make things any better or worse.
With default configuration files supported ( https://reviews.llvm.org/D24933#585615) default language dialect could be
specified by SDK supplier without need to change defaults for entire clang
project.
Projects in active maintainance are mostly migrating to C++11 already.
They don't care about this. But there is a huge existing code base that
doesn't specify -std=XXX and for which bad things can happen. Compile
errors are on the more harmless side of things.
Pointing to GCC doesn't really change anything. They don't maintain
those code bases either.
FTR as of r296554 the default for PS4 target is now C++11.
Because we have a couple of public bots using that default target,
any new tests or changes will need to be tolerant of a C++11 default.
This does not change the default for the world, but at least it will
ensure that tests going forward will be exercising C++11 code paths.
Thanks,
--paulr
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.
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.
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.
And I think that would commit us to keep C++03 forever, which is
untenable. Further, I think expecting the minimal maintenance required
to add "-std=c++03" if a project needs it is not unreasonable.
I'd grudgingly delay the switch if someone came along with a real plan
to do that kind of upgrade on the things they cared about -- on a
specified timescale. But otherwise a sane default is more important
IMO.
From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
To: cfe-dev@lists.llvm.org
Subject: Re: [cfe-dev] Setting default dialect to C++11
> 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" to have our toolchain default
to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.
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.
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.
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.
--paulr
Is it untenable? Why? POLA says to give a reasonable behavior and breaking
existing code is not reasonable. Mandating what standard your code uses
is actually a much saner choice. You are still ignoring my main point:
there is no easy way to tell if a given code base needs -std=c++03.
Older versions of SOCI for example worked perfectly well when compiled
in C++11 mode, until you actually triggered an error. The error case
then was far from pretty.
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.
And I think that would commit us to keep C++03 forever, which is
untenable. Further, I think expecting the minimal maintenance required
to add “-std=c++03” if a project needs it is not unreasonable.
Is it untenable? Why? POLA says to give a reasonable behavior and breaking
existing code is not reasonable.
Though it’s pretty astonishing to new users when they write current C++ and the compiler doesn’t accept it.
The way I see it, there are two categories of users that care about this
change:
1. C++ developers writing new build systems for new code
2. Users attempting to compile legacy C++ applications with legacy build
systems
Raising the default language version is a tradeoff that benefits the first
group and creates work for the second group. I claim that the first group
is larger. C++ as a language is growing, not shrinking. More C++ will be
written in the future than has been written in the past. We can't keep
piling on legacy forever. At some point we have to compromise backwards
compatibility to simplify things for users writing code *today*.
Raising the default improves things for the first group because they can
start to forget about the legacy of C++03/98 etc. People in this group have
already forgotten that pre-C++11 exists, except when they have to touch old
code. I'm in this group. I routinely run `clang -c` on user code samples,
forgetting to pass -std=c++11, and am surprised that we haven't raised the
version yet. All new C++ code is using C++11, so the majority of code I see
is C++11. For me and other such users, it would be nice if the compiler Did
The Right Thing by default.
The second group wants to build legacy code with build systems that are
poorly understood and undermaintained. Frankly, life is already hard for
these users. Clang regularly exploits UB in new and interesting ways that
break old code. This is just a cost of using a new compiler for a language
with undefined behavior. I assume that, as a NetBSD maintainer, Joerg
identifies with this group. I don't see the burden for these users as being
that great, these users can configure legacy projects with something like
'CXX=clang++ -std=c++03' to opt out of the change. Yes, it's work, but I
think the benefits for the larger group outweigh the costs.
I also don't expect that we will ever worry this much about raising the C++
language standard ever again. I predict that future language standards will
be significantly more backwards compatible. However, I'm also prepared to
be wrong, and maybe we'll be doing this song and dance again in 10 years.
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.
And I think that would commit us to keep C++03 forever, which is
untenable. Further, I think expecting the minimal maintenance required
to add “-std=c++03” if a project needs it is not unreasonable.
Is it untenable? Why? POLA says to give a reasonable behavior and breaking
existing code is not reasonable.
Though it’s pretty astonishing to new users when they write current C++ and
the compiler doesn’t accept it.
We already warn for a lot of constructs that they require C++11 or just
allow them in first place in the default mode.
Often in small examples I hit it with library rather than language first - which can be a bit more confusing (“what do you mean you can’t find unique_ptr, I totally included ”).
Vendor do what they want. As an open-source project, I expect more coherency: silently miscompiling a program without changing the option from one platform to another is the kind of portability issue I was mentioning, and this is why I rather error in the driver and require buy in.