similar to: [LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)

2012/11/22 Chandler Carruth <chandlerc at google.com>: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... -> llvm/lib/IR/... > > I've

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > 2012/11/22 Chandler Carruth <chandlerc at google.com>: >> Hello LLVM & Clang hackers! >> >> Based on a discussion with Chris, I would like to propose a Great >> Renaming of Things for the 3.3-era LLVM and Clang codebase. >> >> First and foremost, the two most

Lacking any dissenting opinions, I wanted to give a heads up to folks: I plan to do the two major renamings I mentioned above this weekend. I'll do it over the weekend to try to minimize the number of patches that folks have outstanding touching files in those trees. I'll respond later this week with more details to help sort out any last questions of naming. It looks like the only real

On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at google.com> wrote: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... ->

On Nov 22, 2012, at 3:02 AM, Chandler Carruth <chandlerc at google.com> wrote: >>> First and foremost, the two most significant changes I would like to make: >>> >>> 1) llvm/lib/VMCore/... -> llvm/lib/IR/... >>> >>> I've discussed potential names for the VMCore (or LLVMCore) library >>> with lots of folks, and the best idea

On 11/22/12 04:53 PM, NAKAMURA Takumi wrote: > 2012/11/22 Chandler Carruth<chandlerc at google.com>: >> Hello LLVM& Clang hackers! >> >> Based on a discussion with Chris, I would like to propose a Great >> Renaming of Things for the 3.3-era LLVM and Clang codebase. >> >> First and foremost, the two most significant changes I would like to make:

On Thu, Nov 22, 2012 at 2:49 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: > On 11/22/12 04:53 PM, NAKAMURA Takumi wrote: >> >> 2012/11/22 Chandler Carruth<chandlerc at google.com>: >>> >>> Hello LLVM& Clang hackers! >>> >>> >>> Based on a discussion with Chris, I would like to propose a Great

> Are there other names that are poor choices and are lingering in our > codebases? I'm willing to sign up to do more renames while I'm at > this, so this is a chance to get someone else to do the heavy lifting. > =] Class names too, not just file/directory names? I've been trolling through the integrated assembler lately, and had a real "can't tell the players

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile

Catching up on post-holiday emails. I may have comments on the more general stuff later, but wanted to respond to this bit more quickly. On Nov 22, 2012, at 3:05 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> s/ExecutionEngine/EE/ (or something like buzzword!) > > I don't

> I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( Same here. > > - Michael Spencer Cheers, Rafael

Hi, I think it's an awesome idea to make sure all names are logical. It is an essential feature of a good API to have logical naming :) > I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( On a similar note, all the classes in clang/CodeGen are prefixed with CG or even CodeGen, could those be renamed as well? And speaking of the

On Nov 24, 2012, at 1:02 AM, Tinco Andringa <mail at tinco.nl> wrote: > Hi, > > I think it's an awesome idea to make sure all names are logical. It is > an essential feature of a good API to have logical naming :) > >> I really dislike that all the files and classes in the MC library >> start with MC. This is c++, not c :( > > On a similar note, all

I think this endeavour is good. My request is that there be some words about whatever standard you come up with, probably in the coding standards documentation or at least a link from the coding standards to the file bike shed painting conventions. Don't make this an insider's rule. It is tiresome to have one's commit rejected due to undocumented preferences of the reviewer. Also,

Hi there. What about repainting the top-level bike-shed - the build system itself? I've got a framework called "v3c" in SourceForge that has a top-level makefile. From that makefile you can just do "make" to build it with debug information, "make release" for a release build, "make -j7 distcheck" to throw a few cores at the build, "make -j7 git

On 11/22/2012 12:07 PM, Chandler Carruth wrote: >> While the current naming may not be the best I'm -1 for the change in >> > general. > Are there any serious reasons or concerns? I'm well aware that this > will impose a cost on out-of-tree projects, but on the whole it should > be pretty minimal and consist of some applications of 'sed'. Well, it's a

Hi all, I'm currently in the process of updating the Kaleidoscope tutorials (first and foremost, the ORC/BuildingAJIT ones), and I've noticed a fair few 404s which are lingering within the current visible documentation. Some of these don't seem to have linked to existing pages for a while. I was wondering if there was a way to set up a check in the buildbot to ensure that

I just updated my llvm sources (revision 164794.) and I see the error, "overriding non-deleted function" when building with gcc 4.7.0 and passing -std=c++11. /usr2/sidneym/llvm/tools/install/bin/c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fPIC -fvisibility-inlines-hidden -I/local/scratch/llvm-tmp/build/lib/VMCore

I've fixed this specific error in r164813. Please let me know if there are more behind it. On Thu, Sep 27, 2012 at 2:16 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > I just updated my llvm sources (revision 164794.) and I see the error, > "overriding non-deleted function" when building with gcc 4.7.0 and passing > -std=c++11. > >

The first buildbot failure I can readily find was Monday, 26oct2009 around 7PM PDT. The assertion is Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Volumes/Sandbox/Buildbot/llvm/