On 1/31/2019 9:38 AM, SZEDER Gábor wrote:
On Wed, Jan 30, 2019 at 11:51:04AM -0800, Jeff Hostetler via GitGitGadget wrote:
V3 addresses:
[] incorporate most of the suggestions from clang-format.
Range-diff vs v2:
1: 1a90de9dab < -: ---------- trace2: Documentation/technical/api-trace2.txt
-: ---------- > 1: 60b56d6a8f trace2: Documentation/technical/api-trace2.txt
2: ea39b76d31 ! 2: bfe2fe0bbe trace2: create new combined trace facility
@@ -745,7 +734,8 @@
+ int j;
+ int sum = 0;
+
-+ for_each_builtin(j, tgt_j) {
++ for_each_builtin(j, tgt_j)
++ {
+ if (tgt_j->pfn_init())
+ sum++;
+ }
@@ -763,7 +753,8 @@
+ struct tr2_tgt *tgt_j;
+ int j;
+
-+ for_each_builtin(j, tgt_j) {
++ for_each_builtin(j, tgt_j)
++ {
+ tgt_j->pfn_term();
+ }
Our CodingGuidelines prefer the opening brace on the same line after
the if/for/while/struct/etc. statement, and even omitting the braces
if the if arm or loop body consists of a single statement. So
unfortunately a considerable part of this range diff goes in the wrong
direction.
I know they do and I had them on the same line originally.
Clang-format was complaining about every use of the for_each_builtin
macro, so I changed them to be on the next line to quiet it.
I hesitate to remove braces around a statement adjacent to a
for_each macro trick for the usual safety reasons.
Jeff