similar to: code style for test programs: CamelCase?

I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses capitalized variable names. For instance here

During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. All I'm asking as a kindness if we could

Hi there, At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. For example: - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these

Are there standard naming conventions in LLVM code? Most of the variable, member function, and member variable names seem to be camelcase, beginning with either lowercase or uppercase, or initialisms. But there are exceptions, e.g. some parts of classes dealing with iterators use an STL naming convention with underscores. Is this written down anywhere? Thanks, Cameron

I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. So for me the question is more, are renaming changes worth downstream projects not

I have found layering to be a particularly useful and beneficial model in past large software projects. Is LLVM's layering actually written down anywhere? Last time I went looking, there was nothing. If there's no spec, there's no verifiable conformance; you have to guess based on what other files do. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of

Hi Mehdi! I think the value to upstream (of doing mass reformatting in fewer commits) has to do with the intrusion of nonfunctional commits into `git blame` kinds of research. Every line that someone touches for a formatting reason necessarily obscures the history of functional changes in that block of code. The fewer of those that people have to work around, the better. I admit this is a

On Jan 15, 2011, at 8:31 AM, Matthieu Monrocq wrote: > Hello Doug, > > *putting llvmdev in copy since they are concerned too* > > I've finally got around to finish a working implementation of the typical Levenshtein Distance with the diagonal optimization. > > I've tested it against the original llvm implementation and checked it on a set of ~18k by randomly

Context: I've been looking at experimenting with using Modular Code Generation (My talk at last year's LLVM dev meeting https://www.youtube.com/watch?v=lYYxDXgbUZ0 is about the best reference at the moment) when building the LLVM project, as a good experiment for the feature. This can/does enforce a stronger layering invariant than LLVM has historically been enforced. So I'm curious to

Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody

On Thu, Apr 21, 2016 at 1:57 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Qin Zhao" <zhaoqin at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" <llvm-dev

Hi Philip, While it's true we don't I think Valentin is reasonable in saying "hey, when people do this let's try to combine them if it makes sense". It's just being polite to everyone, especially if it doesn't risk the patches or upstream stability. I don't think there's a policy change being proposed, just a "hey, let's see what we can do in the

On Tue, Jan 16, 2018 at 10:15 AM Robinson, Paul <paul.robinson at sony.com> wrote: > I have found layering to be a particularly useful and beneficial model in > past large software projects. > > > > Is LLVM's layering actually written down anywhere? Last time I went > looking, there was nothing. If there's no spec, there's no verifiable > conformance;

Hi all, As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up: The current variable naming rule [2] states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats). I'm a relatively new arrival to the LLVM codebase and I want to follow the

Hello Doug, *putting llvmdev in copy since they are concerned too* I've finally got around to finish a working implementation of the typical Levenshtein Distance with the diagonal optimization. I've tested it against the original llvm implementation and checked it on a set of ~18k by randomly generating a variation of each word and checking that both implementations would return the

> > > Will this technology allow us to pinpoint specific accesses that generally > have high latency (i.e. generally are cache misses)? This information is > useful for programmers, and is also useful as an input to loop unrolling, > instruction scheduling, and the like on ooo cores. > Won't hardware performance counter tell you which accesses are delinquent accesses? The

Dear all, Given the following vector: > (z <- c('R project', 'hello world', 'something Else')) [1] "R project" "hello world" "something Else" I know how to obtain all capitals or all lower case letters: > tolower(z) [1] "r project" "hello world" "something else" > toupper(z) [1] "R

> On Jan 9, 2017, at 10:29 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9 January 2017 at 18:20, Reid Kleckner <rnk at google.com> wrote: >> I object to the first. If you need a new type name, use a typedef. It's time >> honored and everyone, including C programmers, will know what you're doing. >> I don't understand

On 01/16/2018 09:21 AM, David Blaikie via llvm-dev wrote: > Context: I've been looking at experimenting with using Modular Code > Generation (My talk at last year's LLVM dev meeting > https://www.youtube.com/watch?v=lYYxDXgbUZ0 is about the best > reference at the moment) when building the LLVM project, as a good > experiment for the feature. This can/does enforce a

> On Jan 9, 2017, at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 9 January 2017 at 19:04, Mehdi Amini <mehdi.amini at apple.com> wrote: >> This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formatting > > You mistake the tone of the