clang-format all code

clang-format all code

Created by:

  find . -name '*.cpp' -o -name '*.h' | \
  grep -E -v 'thirdparties|fxcodec/fx_zlib/zlib_v128/|fx_libopenjpeg/libopenjpeg20/|fxcodec/lcms2|fxcodec/libjpeg|fxge/fx_freetype/|fxge/agg/agg23/|CNS1|GB1|Japan1|Korea1' | \
  xargs ~/src/llvm-build/bin/clang-format -i

BUG=

[Tom Sepez, 2014-08-12 18:19:14]

drive-by:  I should probably just be quiet, since this is much better, but
having read through a lot of pdfium code recently, a few changes clang-format is
making would annoy me.

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_pa...
File core/include/fpdfapi/fpdf_parser.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_pa...
core/include/fpdfapi/fpdf_parser.h:40: #define FPDFPERM_PRINT 0x0004
I find these harder to read after formatting.  We don't have a lot of these
C-style bit-flag defines in chromium, wondering if chromium-style is
appropriate.

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_re...
File core/include/fpdfapi/fpdf_render.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_re...
core/include/fpdfapi/fpdf_render.h:80: class CPDF_RenderContext : public
CFX_Object {
Could we teach clang-format to put a newline between two consecutive classes?

https://codereview.chromium.org/453133004/diff/1/core/include/fxcrt/fx_coordi...
File core/include/fxcrt/fx_coordinates.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fxcrt/fx_coordi...
core/include/fxcrt/fx_coordinates.h:9: template <class baseType>
I found this clearer without the newline.

https://codereview.chromium.org/453133004/diff/1/core/src/fdrm/crypto/fx_cryp...
File core/src/fdrm/crypto/fx_crypt_aes.cpp (right):

https://codereview.chromium.org/453133004/diff/1/core/src/fdrm/crypto/fx_cryp...
core/src/fdrm/crypto/fx_crypt_aes.cpp:37: 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b,
0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe,
These made more sense before reformat with 8 per line

[Nico, 2014-08-12 18:29:39]

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_pa...
File core/include/fpdfapi/fpdf_parser.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_pa...
core/include/fpdfapi/fpdf_parser.h:40: #define FPDFPERM_PRINT 0x0004
On 2014/08/12 18:19:14, Tom Sepez wrote:
> I find these harder to read after formatting.  We don't have a lot of these
> C-style bit-flag defines in chromium, wondering if chromium-style is
> appropriate.

rietveld happens to have the right tab size here. With ts=2, the "before"
picture looks less nice.

Having said that, I agree (filed http://llvm.org/PR20637), but it seems minor.

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_re...
File core/include/fpdfapi/fpdf_render.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fpdfapi/fpdf_re...
core/include/fpdfapi/fpdf_render.h:80: class CPDF_RenderContext : public
CFX_Object {
On 2014/08/12 18:19:14, Tom Sepez wrote:
> Could we teach clang-format to put a newline between two consecutive classes?

I had the same thought. I guess it's currently not done because the style guide
says "minimize vertical space", it's easy to add manually, and adding it
manually doesn't break blame output on existing lines (it just adds a new line).

I filed http://llvm.org/PR20636 since asking won't hurt, but that's my guess at
their reasoning. clang-format won't remove the newline either, so we can just
add it manually after formatting everything.

https://codereview.chromium.org/453133004/diff/1/core/include/fxcrt/fx_coordi...
File core/include/fxcrt/fx_coordinates.h (right):

https://codereview.chromium.org/453133004/diff/1/core/include/fxcrt/fx_coordi...
core/include/fxcrt/fx_coordinates.h:9: template <class baseType>
On 2014/08/12 18:19:14, Tom Sepez wrote:
> I found this clearer without the newline.

I think this is a style option (
http://clang.llvm.org/docs/ClangFormatStyleOptions.html ,
AlwaysBreakTemplateDeclarations ), so this was something that someone
intentionally did the way it is.

https://codereview.chromium.org/453133004/diff/1/core/src/fdrm/crypto/fx_cryp...
File core/src/fdrm/crypto/fx_crypt_aes.cpp (right):

https://codereview.chromium.org/453133004/diff/1/core/src/fdrm/crypto/fx_cryp...
core/src/fdrm/crypto/fx_crypt_aes.cpp:37: 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b,
0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe,
On 2014/08/12 18:19:14, Tom Sepez wrote:
> These made more sense before reformat with 8 per line

If you feel strongly about this, we could surround these blocks with

 // clang-format off
...
 // clang-format on

but in that case it just looks like a bunch of bytes that likely will never
change, so the output seems fine?

[Tom Sepez, 2014-08-12 18:36:29]

Mostly in agreement with you.

> but in that case it just looks like a bunch of bytes that likely will never
> change, so the output seems fine?
I only mention this because the array is of [256] bytes, finding a particular
byte via "2D visual indexing" in a power of two sized array is easier when the
row count is a power of two ...

[Lei Zhang, 2016-10-05 01:37:34]

Description was changed from

==========
clang-format all code

Created by:

  find . -name '*.cpp' -o -name '*.h' | \
  grep -E -v
'thirdparties|fxcodec/fx_zlib/zlib_v128/|fx_libopenjpeg/libopenjpeg20/|fxcodec/lcms2|fxcodec/libjpeg|fxge/fx_freetype/|fxge/agg/agg23/|CNS1|GB1|Japan1|Korea1'
| \
  xargs ~/src/llvm-build/bin/clang-format -i

BUG=
==========

to

==========
clang-format all code

Created by:

  find . -name '*.cpp' -o -name '*.h' | \
  grep -E -v
'thirdparties|fxcodec/fx_zlib/zlib_v128/|fx_libopenjpeg/libopenjpeg20/|fxcodec/lcms2|fxcodec/libjpeg|fxge/fx_freetype/|fxge/agg/agg23/|CNS1|GB1|Japan1|Korea1'
| \
  xargs ~/src/llvm-build/bin/clang-format -i

BUG=
==========