similar to: State of llgo in monorepo?

Yep - delete it. If someone wants it back they can resurrect it from version control & explain why it's worth adding back in. On Mon, Feb 10, 2020 at 9:17 AM Jonas Devlieghere via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for bringing this up! Strong +1 from me for all the reasons > you've mentioned. > > On Mon, Feb 10, 2020 at 8:42 AM Raphael Isemann

Sure, that's fine with me. Peter On Mon, Feb 10, 2020 at 9:57 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Calling pcc real fast :) > > -eric > > On Mon, Feb 10, 2020 at 9:49 AM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Yep - delete it. If someone wants it back they can resurrect it from >>

Done thusly: echristo at athyra ~/r/llvm-project> git push To github.com:llvm/llvm-project.git 936d1427da1..372bfc65deb master -> master On Mon, Feb 10, 2020 at 10:02 AM Eric Christopher <echristo at gmail.com> wrote: > OK. I'll get it. > > -eric > > On Mon, Feb 10, 2020 at 9:58 AM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Sure,

Nope, it wasn't all reverted -- the llgo implementation remains deleted. There's been some confusion borne out of unfortunate naming -- only the file "llvm/tools/llvm-go/llvm-go.go" was reinstated. Despite its confusing name, this tool is *not* a go implementation, and has effectively nothing to do with llgo. It's only a tiny utility script used by the llvm build process for

"The llgo frontend has been removed for now, but may be resurrected in the future." Thoughts? -eric On Tue, Aug 25, 2020 at 2:18 PM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone add a mention about the llgo removal to the release notes? > > Thanks, > Hans > > On Fri, Feb 14, 2020 at 3:40 PM James Y Knight via llvm-dev >

On Tue Nov 25 2014 at 18:30:08 Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > Just curious: are you considering the possibility of enabling LTO across > user and runtime code? > Since AFAIK the product of go build is almost always a statically-linked > executable, I guess it would make sense (when doing an optimised build) to > feed the runtime to the linker in IR

Hi all, I'd like to propose the contribution of a Go frontend subproject to the LLVM project, based on the existing llgo project at https://github.com/go-llvm/llgo . As with the previous contribution of the Go bindings, I have obtained permission from all llgo contributors whose code is part of this contribution, to contribute their changes to the LLVM project and relicense their changes

I am planing to add projects into https://github.com/llvm-project/llvm-project in near future, possibly this week. Before doing that, I would like to ask users of it. 1st option is my preference in each paragraph. Let me know if you have other suggestions. * What is added? I will add; libunwind, llgo, openmp and parallel-libs. May I also add debuginfo-tests? * Will inactive projects be

On Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote: > > llgo depends on certain third-party components, namely a copy of the Go > > standard library (libgo), a Go program analysis library (go.tools) and two > > library dependencies of the standard library (libbacktrace and libffi). >

On Sun, May 7, 2017 at 12:07 AM, NAKAMURA Takumi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I have done just now. 5 repos added including debuginfo-tests. > ATM, it includes 17 repos total. > > - Created the new repo; https://github.com/llvm- > project/llvm-project-20170507.git > Branches will come later. > - The previous repository has a merge commit that

Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it. I have recently been working on bring-up for libc++ and libunwind on a new platform and the integration of libunwind with the LLVM build system is already annoying (you can’t build it unless you have a working C++ standard library

Hi folks, phabricator maintenance is a topic that has been lying dormant for a while now. That subsequently creates a non-optimal user experience. For me personally, given that github provides a secure PR infrastructure, the additional effort required to keep Phab going is not an investment I'm personally willing to make. I understand that there are unique selling points for Phab in its UI

cc Paul / MyDeveloperDay De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David Blaikie via llvm-dev Envoyé : April 8, 2020 10:21 PM À : Raphael “Teemperor” Isemann <teemperor at gmail.com>; Manuel Klimek <klimek at google.com> Cc : llvm-dev <llvm-dev at lists.llvm.org> Objet : Re: [llvm-dev] Outdated Phabricator version on reviews.llvm.org breaks Google

Just my 2 cents here: we are working on enabling this as a part of bugzilla migration as PRs and issues are very tied inside GitHub. Stay tuned for updates! On Fri, Jun 19, 2020 at 3:45 PM Manuel Klimek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -Chris' outdated email, +Chris' correct email :) > > On Fri, Jun 19, 2020 at 2:01 PM Manuel Klimek <klimek at

On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just my 2 cents here: we are working on enabling this as a part of >> bugzilla migration as PRs and issues are very tied inside GitHub. Stay >> tuned for

On Fri, 19 Jun 2020, 18:55 Hubert Tong, <hubert.reinterpretcast at gmail.com> wrote: > On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just my 2 cents here: we are working on enabling this as a part of >> bugzilla migration as PRs and issues are very tied inside GitHub. Stay >> tuned for updates!

Hi all, I’m using my Google account to log into my Phabricator account on reviews.llvm.org . Since today that no longer works as I don’t seem to get any reply from reviews.llvm.org when I’m logged into my account. It tried logging out which fixes the issue of reviews.llvm.org not loading, but when I try to login I just get the following error: > Expected to retrieve an "account"

On Mon, Jun 22, 2020 at 2:33 AM Manuel Klimek <klimek at google.com> wrote: > On Fri, Jun 19, 2020 at 10:04 PM Mehdi AMINI via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> >> >> On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Jun 19, 2020 at 12:32 PM Anton

On Fri, Jun 19, 2020 at 1:15 PM Keith Smiley <keithbsmiley at gmail.com> wrote: > FWIW GitHub's code review tools have improved significantly in the past > few years. At this point with reviews and manual control over resolving / > unresolving comments I think many previous complaints I've seen about > GitHub vs Phabricator have been alleviated. > To be clear: this

Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style? I’m in general in favor of moving LLDB to the LLVM code style because it makes the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no more code style confusion when inheriting from a Clang classes inside the LLDB code base). But I think if we do