similar to: [LLVMdev] LLD vs LLVM coding style...

On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote: > The lld conventions for ivars is a leading underscore followed by a > lowercase letter. The reserved identifiers are a leading underscore > followed by an uppercase letter. There is no conflict. > And I didn't say that there was. They are *close*. Too close. People make mistakes and get it wrong.

On Wed, Oct 8, 2014 at 4:58 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 8, 2014, at 9:34 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Oct 8, 2014, at 1:55 AM, Renato Golin <renato.golin at linaro.org> > wrote: > >> On 8 October 2014 05:25, Chris Lattner <clattner at apple.com> wrote: > >>>> Up until now the

On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote: > Sure, I actually have no problem with this. > > I'm going to point out that one of the naming conventions used by LLD has > serious problems: naming variables with a leading underscore puts them > *way* too close to the reserved identifier space. Folks have accidentally > ended up with

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that.

On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote: > Sorry, I wasn't trying to suggest anything vague, but rather refer to my previous (perhaps ill founded) understanding about the expected path forward for LLD. Anyways, I'll explain in a bit more detail so we can talk about the concrete issue. > > My concrete hope is that LLD migrates toward the coding standards that are

On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. > > My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support

On Sun, Jan 20, 2013 at 8:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > > We're looking more at doing some serious hacking on LLD, and I'd like to > avoid doing lots of work in the codebase only to change the style around > later. > > > > My understanding was that LLD was always intended to

> On Oct 8, 2014, at 1:55 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 8 October 2014 05:25, Chris Lattner <clattner at apple.com> wrote: >>> Up until now the thread has been about “formatting”. You suggested renaming >>> every variable in the project! >> >> If that's what it takes. > > If we're still talking about

Greetings folks, We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support libraries. Can we start that migration? I'm really

Looks like most people in this thread support using LLVM style in LLD. I also had an offline discussion and many people wanted to have one coding style in all LLVM projects. So I'm convinced that we should do that. I'm going to create a patch to rename all variables if no one objects. On Mon, Oct 6, 2014 at 3:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Tue, Oct 7, 2014

On Tue, Jan 22, 2013 at 12:36 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote: > > Sorry, I wasn't trying to suggest anything vague, but rather refer to my > previous (perhaps ill founded) understanding about the expected path > forward for LLD. Anyways, I'll explain in a bit more detail so we can talk > about

On Oct 6, 2014, at 6:03 PM, Nick Kledzik <kledzik at apple.com> wrote: >> I'd like to hear the reason. :) > > Up until now the thread has been about “formatting”. You suggested renaming every variable in the project! If that's what it takes. > On Oct 6, 2014, at 5:37 PM, Chris Lattner <clattner at apple.com> wrote: >> Right. Specifically, why is it

I think we need a straw man proposal to start iterating on. Clang’s diagnostics has lots of good features. But is has lots that a linker does not need. For instance, the line/column number does not make sense for a linker. Clang errors/warnings are mostly about the source language which is pretty standard across different platforms. Other than multiple-defined and undefined errors, most of

On Wed, Jan 2, 2013 at 2:53 PM, Nick Kledzik <kledzik at apple.com> wrote: > The SECTION and MEMORY seem doable in lld as part of the ELF > Writer. MEMORY and most aspects of SECTIONS are effectively syntax sugar and the rest of LLD doesn't need to even be aware of it; the ldscript language processor will desugar it. The same is true of many other linker script constructs that I

On Mon, Oct 7, 2013 at 4:02 PM, Nick Kledzik <kledzik at apple.com> wrote: > But is has lots that a linker does not need. For instance, the > line/column number does not make sense for a linker. > Really? Gold has errors that mention lines and columns. It gets them by querying the debug information for file, line, and column. There may be examples of this, but I don't think

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >

On Jan 2, 2013, at 5:51 PM, Sean Silva wrote: >> The one tricky part will be if the linker script defines symbols >> (e.g. __text_size), because those symbol names might be >> referenced by some object file atom. Thus they need an atom >> representation for lld's Resolver to see. So, the ELF Writer will need >> to make a first pass at the linker script and make

Sean, Thanks for doing this research and writing up that summary! The SECTION and MEMORY seem doable in lld as part of the ELF Writer. The one tricky part will be if the linker script defines symbols (e.g. __text_size), because those symbol names might be referenced by some object file atom. Thus they need an atom representation for lld's Resolver to see. So, the ELF Writer will need

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

On 1/22/2013 4:15 PM, Chandler Carruth wrote: > > A different naming convention is one of the most disruptive things to > have change between two code bases. It will cause people to habitually > write code one way, realize they are submitting to the other repository, > and have to mechanically go and rename all their variables. While I > personally like your naming convention