.clang-format (Diff revision 1)

we usually do not use this style

Show all issues

.clang-format (Diff revision 1)

we usually do not use this style

Show all issues

.clang-format (Diff revision 1)

78 or 76 I would say

Show all issues

Somehow we need to be able to tell clang to put the return type on a separate line for methods. This is one major difference with how things are done at the moment.

The way we format our stats is also a bit of an odd one with the 

name
.init
.desc

etc. the formatter really does not like this, and I'm not sure what to do about it.

I looked into this tool a couple of months ago. At the time, I encountered some issues relating to indentation (IIRC, the way we indent case labels by 2 spaces wasn't supported). My conclusion at the time was that it wasn't possible to configure clang-format to adhere to the gem5 style. Has this changed? If not, I'd suggest that we don't commit this for now and wait while clang-format matures.

.clang-format (Diff revision 1)

Shouldn't this be -2?

Show all issues

.clang-format (Diff revision 1)

I used 78 here.

Show all issues

.clang-format (Diff revision 1)

Has this changed name? The clang documentation lists DerivePointerAlignment, but not DerivePointerBinding.

Show all issues

1. Nilay Vaish Sept. 2, 2014, 9:53 p.m. (Sept. 2, 2014, 9:53 p.m.)

   Documentation for version 3.4 lists DerivePointerBinding.

2. Andreas Sandberg Sept. 3, 2014, 5:14 a.m. (Sept. 3, 2014, 5:14 a.m.)

   That explains it. I was looking at the 3.6 documentation. (http://clang.llvm.org/docs/ClangFormatStyleOptions.html)

.clang-format (Diff revision 1)

Shouldn't this be 'Linux'? That'd add a newline after function/namespace/class definitions.

Show all issues

.clang-format (Diff revision 1)

??

Show all issues

1. Nilay Vaish Sept. 2, 2014, 9:53 p.m. (Sept. 2, 2014, 9:53 p.m.)

   The file was originally file generated using clang-format and the ellipsis came with it.