similar to: [RFC] Let's add a CONTRIBUTING.md file to llvm-project

Hello all, I am a grad student looking to get my hands wet contributing to LLVM. I have done an undergrad course in Compilers. I have some knowledge of parsers, code generation, optimization, IR and other topics taught in an undergrad course. I have worked through quite a bit of the dragon book. Is there a guide to get newbie devs up to speed on the process of contributing? Do I just build the

Hi, I'm in the process of adding support for Markdown to a minimal CMS in Rails, [Railfrog][railfrog], which uses mime types to select appropriate processing. I have had a look through the archives but have not been able to see that a consensus has emerged as to what such a mime type for Markdown should look like. My reading of the RFCs suggests that it should be within the "text/*"

In an effort to streamline and consolidate how code gets submitted to puppet, we''ve updated the contributing guidelines. The changes were along three fronts: 1. Clarify what to target when submitting patches. 2. Reflect the reality that we take code submissions as github pull requests. 3. Simplify the explanation for how to get up and running as a contributor. We are also in discussions

Hi, it seems like http://llvm.org/docs/ stopped updating around 2018-01-03 (the footer at http://llvm.org/docs/ says `Last updated on 2018-01-03`). I've committed a new page [1], on the 4th but it does not show up yet. I could not find any public logs of the doc-builder. It would be great it someone could have a look. Cheers, Florian [1]

Hi all. I'm assuming most people reading this email are familiar with LLVM's code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> as well as LLVM Weekly, the development newsletter I've written and sent out every Monday since Jan 2014. Since that time, it's provided something of a "signal boost" for important mailing list discussions and

Hello all, We would like to contribute a new backend for Qualcomm's Hexagon processor. We will actively maintain the port once it is accepted. Hexagon is a VLIW core that is used principally in modem and low power audio applications in Qualcomm's chip sets. We have a patch for both llvm and for clang. As this is a new port, these patches are quite large (approximately 26k and 3k

Hi LLVM and CLang Devs, At the moment my company (Movidius) is considering contributing the changes we have made to LLVM and CLang in order to support our proprietary processor, and I would like to seek advice on how best to approach doing this? I am pretty sure that there are coding guidelines and conventions that we should be following but have not followed over the course of the last few

On Tue, Nov 1, 2011 at 11:44 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: > Hello all, > > We would like to contribute a new backend for Qualcomm's Hexagon > processor.  We will actively maintain the port once it is accepted. > Hexagon is a VLIW core that is used principally in modem and low power > audio applications in Qualcomm's chip sets. > > We

I'd rather we decided on whether to accept GitHub PRs or not first (in the other thread). I would bet that everyone who has troubles with arc / is not allowed to use arc would happily use GitHub PRs instead. Worst case scenario if the community decides that we don't want to accept GitHub PRs then this sort of script would be a useful time sink. Cheers, -Neil. On Tue, Jan 21, 2020 at

>> Ideally we would have a >> docs/SystemLibrary.rst that would just says "this library has been >> merged to lib/Support" and docs/SupportLibrary.rst documents whatever >> is in lib/Support. > > > Considering our OS portability layer to be it's own separate thing, even if > it isn't its own lib/* directory is probably a good distinction to

On 25/12/2017 18:10, Philip Reames via llvm-dev wrote: > I just went through and added a bunch I'd collected. We seem to be up > to around 45 with a fairly decent spectrum of areas covered. > > Another source of potentially good starter bugs would be the output from > the various fuzzers. Many of those tend to be small fixes, but they > might present a challenge getting

Hi, One takeaway for me from the recent Phabricator vs Github PR discussions was that arc (arcanist) can be a pain to set up and may pose a hurdle for some contributors. I think those points could be addressed relatively easily by adding a llvm-patch script (or an even better name) that allows users to create and apply patches from reviews.llvm.org using Phabricators API. In my experience, the

On 28/12/2017 18:06, Robinson, Paul wrote: > > >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >> Philip Reames via llvm-dev >> Sent: Tuesday, December 26, 2017 11:30 AM >> To: Florian Hahn; Tanya Lattner; llvm-dev >> Cc: Clang Dev >> Subject: Re: [llvm-dev] Beginner Bugs - Need help tagging >> >>> >>> I

Hello, I came across the file *omega.cc* which is in directory* xapain-application/omega/* In this file , atoi is used in *Percentage Relevance cutoff *(293 line no) as Percentage lies between 0-100 their is no need to modify atoi . But do we need to check for error's ? Second Implementation is in *collapsing* (301) in which we collapse set of document under a key,range of this key has not

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

Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key

I hit upon docs/SystemLibrary.rst today. Is this documentation useful to anyone? Can I delete it? Most of the guidelines seem like common sense: Keeping LLVM Portable, High Level Interface, No Unused Functionality, No Duplicate Implementations, etc. Some are not really true, like "Minimize Soft Errors". We currently propagate a lot of file-related soft errors up as

There’s also some feature regressions in GH vs Phab. You *must* initiate a review via a pull request, and pull request by definition compares your working copy against master. This is not very compatible with LLVMs approach to incremental development. For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff

Hi Adit, On Tue, May 22, 2018 at 11:10 AM, Adit Mehta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am Adit Mehta first year student of DA-IICT. I know C/C++, python, ruby, > PHP. I am new to llvm. I am interested in contributing to llvm. Can you > guide me from where should I start? A good place to start is the Kaleidoscope tutorial: https://llvm.org/docs/tutorial/ It

On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time Would it be practical to use merge commits during review (never rebasing) & then rebasing/squashing to