llvm dev - Oct 2013 - [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On 10/29/13 07:27 AM, Chandler Carruth wrote:
> On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" 
> <cbergstrom at pathscale.com <mailto:cbergstrom at
pathscale.com>> wrote:
>
>     fuzzy://How much "heads up"
>
>
> One full release cycle, so approximately 6 months before a release
If it's 3-6 months from *today* before something hits clang svn trunk 
that should be enough time to address any problems. (Such as testing 
libc++ more extensively and or sending any patches if necessary) I don't 
know the 3.4 release timeline and if you want to adopt this immediately 
after that has branched. [My other points below can be ignored if this 
is true]






---------------------------------
> incorporating this. In addition, probably several weeks to a month 
> between the initial branch for the 3.4 release and the commits that 
> make this so. Still more weeks between when we put it into the release 
> notes for 3.4 and blog about it.
>
>     -1
>     If we do it - we should do it properly.
>
>
> We're not talking about doing it improperly, but about doing two 
> independent things independently.
>
>     ---------
>     I'm strongly against anything which forces this to rely on gnu
>     runtime and libs.
>
>
> You are not being forced to rely on anything. Many people have 
> successfully bootstrapped with libc++, and if you find issues with 
> your setup doing such a bootstrap, patches to fix that would be very 
> welcome.
>
> And moreover, a requirement to not use GNU runtimes or libraries in 
> the bootstrap would be totally novel for the project. LLVM and Clang 
> require xlC and MSVC to bootstrap on certain platforms, and you're OK 
> with that? There are plenty of platforms with no Clang port at all but 
> where GCC works fine, and we rely on a GCC host there. This is not 
> new, and not something we should burden the discussion about C++11 
> features with.
On linux amd64/intel64 is what I meant by "regression". The other 
platforms you reference are still work-in-progress. It wasn't my 
intention to include them as a blocker - (just to
clarify)
>
>     ---------
>     Further - While c++11 is the best thing ever - Is there actually a
>     driving use case where using c++11 features will significantly
>     improve the quality of the codebase?
>
>
> Yes. See my first email for some of them. See numerous other 
> discussions. Have you tried writing any code with C++11?
Cherry picking the points from your original email.
>
> Some notable features we would get to use:
>
> - r-value references, move semantics, etc
> - auto
> - range for loops
> - lambdas
> - static_assert
> - nullptr
> - std::unique_ptr, std::tuple, some other nice library stuff
>
>
I'd love to see/review an updated style guideline before anything hits 
SVN trunk so that it's super clear on what's allowed. Maybe I'm too 
conservative, but it's still fuzzy on how using some of those features 
would benefit the compiler internally.

Usage of c++11 code in applications (chrome) and the compiler are 2 
different worlds to me. You ask if I write c++11 codes - No, but 
increasingly I do see it being used in production and forced to deal 
with it. Sometimes it makes sense and sometimes I think meh or wtf -

If it doesn't make the code:
     a. easier to read
     b. easier to write
     c. higher performance

it has no value or negative value.

--------------------------
I don't mean to nit-pick||troll and I'm not opposed to this idea at all 
- I just like to have specifics and facts. (Please feel free to ignore 
these questions below)
> It also would have the benefit of removing divergence between LLVM 
> sub-projects already using C++11 features
Which sub-projects would this benefit?
>
> There is increasing pressure for LLVM to make use of new C++ language 
> and library features.
pressure from where? (sub-projects, google.. ?)
>
> I have historically been more conservative on this topic, but 
> listening to many people and looking at some of the C++ features we 
> are missing
watercooler or mailing list?
>
>
> These days, this list seems increasingly worth the cost of forcing 
> users to get a modern toolchain onto their systems.
>
I'm all for modern toolchains, but a modern toolchain requirement and 
depending on c++11 features are independent issues. You could make a 
policy that ______ doesn't care about building and supporting gcc-3.x on 
________ old ${platform} - I'm cool with that, but it doesn't mean we 
must rely on c++11 in the process.

On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at
pathscale.com>wrote:
> On 10/29/13 07:27 AM, Chandler Carruth wrote:
>
>  On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <cbergstrom
at pathscale.com<mailto:
>> cbergstrom at pathscale.**com <cbergstrom at
pathscale.com>>> wrote:
>>
>>     fuzzy://How much "heads up"
>>
>>
>> One full release cycle, so approximately 6 months before a release
>>
> If it's 3-6 months from *today* before something hits clang svn trunk
that
> should be enough time to address any problems.

No, it's 1 month, maybe 2 before something hits trunk, and over 6 months
before something hits a release.

> (Such as testing libc++ more extensively and or sending any patches if
> necessary) I don't know the 3.4 release timeline and if you want to
adopt
> this immediately after that has branched. [My other points below can be
> ignored if this is true]
>
I don't think there is any need for further testing. Others have reported
no issues here, so I suspect the problem is on your end and something you
can sort out.

>
>
>> Some notable features we would get to use:
>>
>> - r-value references, move semantics, etc
>> - auto
>> - range for loops
>> - lambdas
>> - static_assert
>> - nullptr
>> - std::unique_ptr, std::tuple, some other nice library stuff
>>
>>
>>  I'd love to see/review an updated style guideline before anything
hits
> SVN trunk so that it's super clear on what's allowed. Maybe I'm
too
> conservative, but it's still fuzzy on how using some of those features
> would benefit the compiler internally.
>
> Usage of c++11 code in applications (chrome) and the compiler are 2
> different worlds to me. You ask if I write c++11 codes - No, but
> increasingly I do see it being used in production and forced to deal with
> it. Sometimes it makes sense and sometimes I think meh or wtf -
>
You're certainly welcome to your opinions. =] Others have consistently
expressed the other opinion, and my priority is toward those actively
contributing patches and reviews to the project. Of those, there has been a
widespread and strong support for adopting C++11 features. If you see code
being committed during code review which has questionable value, you should
provide the review and articulate there why the C++98 construction would be
preferable.


>  It also would have the benefit of removing divergence between LLVM
>> sub-projects already using C++11 features
>>
> Which sub-projects would this benefit?

As has been mentioned repeatedly, LLD.

>
>
>> There is increasing pressure for LLVM to make use of new C++ language
and
>> library features.
>>
> pressure from where? (sub-projects, google.. ?)

Those contributing patches, reviewing patches, and writing the code that
makes up LLVM's various projects.

>
>
>> I have historically been more conservative on this topic, but listening
>> to many people and looking at some of the C++ features we are missing
>>
> watercooler or mailing list?

All of the above. There have been plenty of discussions on the mailing
lists and it patch review that ended up being "yes, it would be great if we
could do that, but we don't have X feature in C++11, so we have to do this
ugly thing over here".

> These days, this list seems increasingly worth the cost of forcing users
>> to get a modern toolchain onto their systems.
>>
>>  I'm all for modern toolchains, but a modern toolchain requirement
and
> depending on c++11 features are independent issues. You could make a policy
> that ______ doesn't care about building and supporting gcc-3.x on
________
> old ${platform} - I'm cool with that, but it doesn't mean we must
rely on
> c++11 in the process.
>
Nor have I indicated we must rely on C++11. Rather, I'm saying that there
is a strong desire to have C++11, and doing so requires moving forward in
terms of the toolchains we support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/8df80b63/attachment.html>

On 10/30/13 03:17 AM, Chandler Carruth wrote:
> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" 
> <cbergstrom at pathscale.com <mailto:cbergstrom at
pathscale.com>> wrote:
>
>     On 10/29/13 07:27 AM, Chandler Carruth wrote:
>
>         On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström"
>         <cbergstrom at pathscale.com <mailto:cbergstrom at
pathscale.com>
>         <mailto:cbergstrom at pathscale.com
>         <mailto:cbergstrom at pathscale.com>>> wrote:
>
>             fuzzy://How much "heads up"
>
>
>         One full release cycle, so approximately 6 months before a release
>
>     If it's 3-6 months from *today* before something hits clang svn
>     trunk that should be enough time to address any problems.
>
>
> No, it's 1 month, maybe 2 before something hits trunk, and over 6 
> months before something hits a release.
I'm objecting to 1 month for svn trunk - 2 months notice is even pushing 
it imho.

1) This is imho not the small change which it's being presented as
2) As someone else stated - there are projects tracking svn trunk and 
telling them to just stop doing that and follow the previous release is 
untenable without sufficient notice. (It just doesn't seem fair)

May I humbly propose you create a c++11-development branch 
now/later/anytime and let people start using that. In parallel to that 
let people know that pieces of the c++11 branch will potentially start 
merging Feb 1st 2014. (roughly 3 months from today). This gives people 
time to review things before they hit trunk, test, discuss and 
experiment in a way that virtual discussions simply can't flush out. 
This hopefully won't hurt your target of the release-after-next using 
more modern toolchains and is *hopefully* a win-win in your view.