similar to: A Short Policy Proposal Regarding Host Compilers

I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073 With the intent of either implementing this policy change, or encouraging further discussion/bikeshed. Thanks all! -Erich -----Original Message----- From: Brooks Davis [mailto:brooks at freebsd.org] Sent: Sunday, May 13, 2018 10:34 AM To: Keane, Erich <erich.keane

I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5. On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi All- > As we all know, the C++14 discussion is flaring up again. Chandler > brought up that he would like a concrete plan to switch. In my opinion, > this is insufficient, as it will result in us simply

I’d like us to move forward with something along the lines Erich proposed back in May, ideally early enough in the LLVM 8 release process that people testing the release will be able to provide feedback. Are there any remaining concerns? > On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all- > I just wanted to bump this again,

On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote: > Hi All- > As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host

Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/) 6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn. 6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1). -Erich From: Andrew Kelley

I'd be opposed to 6/5, given where it would leave us. It's simply hard to see a compelling reason to leave things that long. In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of

> On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > I'm a bit puzzled as of why would a fix period of time be the best option to automatically cut support for older compilers? > > Historically I believe we've been looking at a combination of: > > 1) What new feature we gain by dropping support for a given version of the compiler >

Hi, @Erich, thanks for putting this together :). > On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd be opposed to 6/5, given where it would leave us. > It's simply hard to see a compelling reason to leave things that long. > > In particular, given this is about what it takes to produce a binary release of

To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE. I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less

I mean, we could change it twice? There are about a hundred scripts out there for doing it. -eric On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote: > Do we have any ability to reach out to github (at least?) to see what they > are going to do? I’d very much like to avoid being the odd-project-out > here. > > > > > > > >

I disagree with your timing concerns. Changing is still straightforward and I'd like to see this done within 1-2 weeks. Thanks. -eric On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > +1 to waiting until git and/or github decide on a new name for the default > branch. I think there is a compelling reason to change the name of the > default

Sorry for the inline-comment format being weird, I haven't figured out yet how to do '>' stuff in outlook yet :/ Hopefully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re:

As I mentioned on another thread, we also use the term "slave" for the BuildBot builders. In the past, I was told this was due to being stuck on an old version of BuildBot. Fortunately, there is already work in progress to update BuildBot to a newer version. Since that's also going affect all the build machines, perhaps changing the name of the main branch should happen

That's a good point, we should definitely be respectful of the build bot owners time, that said I think it's the coordination that takes the time rather than the change :) On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding is the biggest concern about the name change is the > ‘cost’ associated with needing to

There's really no guarantee that things will shake out the same in near term between the projects. -eric On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote: > I’m a bit mixed on this. While yes, we should change this as soon as is > practical, it would be a shame to pick something sufficiently different > from the rest of the world, as that would

Alright, I guess it isn’t just my pain then, it makes it feel better ☺ I think that proposed feature would be really nice, since it would encourage people to write tests that have a //CHECK: some-thing-after-header first! From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, March 30, 2017 11:15 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject:

Ah, I see what you mean. I would have no problem with January 7th being pushed back a while if that helps out your transition. Would that be possible Mike? From: Stephen Hines <srhines at google.com> Sent: Monday, November 16, 2020 6:03 PM To: Keane, Erich <erich.keane at intel.com> Cc: Mehdi AMINI <joker.eph at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang

Stephen, does that help you out? From: Mike Edwards <mike at sqlby.me> Sent: Wednesday, November 18, 2020 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: Stephen Hines <srhines at google.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>; Mehdi AMINI <joker.eph at gmail.com> Subject: Re: [llvm-dev] Renaming

Hi all- I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advance. I was looking into some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following:

> On Dec 14, 2016, at 9:37 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > One of my coworkers noticed that we(Clang/LLVM) have quite a few places where we need to iterate through 2 equally sized ranges at the same time, often related to parm/arg relationships. In a few cases we(Clang/LLVM) use a traditional for-loop with 2 iterators in it. In a few others,