On 16.06.20 05:32, Ben Campbell wrote:

+1

On 2020/06/16 14:22, Ben Bucksch wrote:

So, mozilla/comm/.clang-format will be gone?

There has been a mention of this .clang-format not observed  for local 
c-c tree
reformatting.  (I had to copy .clang-format to various temporary
directories just in case when I tried to re-format local C-C tree after
I landed my patches locally.)

What would be the use case?

• We no longer have mozilla/comm/.clang-format. (?)

• For local reformatting under C-C subtree, we still need to copy then,
  the mozilla/.clang-format to various temporary variables or something (?)

BTW, M-C tree has mozilla/.clang-format-ignore and looking at that file
suggests there are valid exceptions to the reformatting.
I am not sure how the mochitest and xpcshell-tests  test files are
exempted from reformatting under comm-central subdirectory.

My understanding was that the earlier reformatting was done by Jorg last
year.
Are similar processing going to be done by someone who selectively chose
subdirectories of C-C tree to be reformatted?

Anyway, the handling of top-level .clang-format or the potential
introduction of .clang-format-ignore
should be clarified for long-term maintanance.

I particularly don't have an opinion on automatic reformatting as long
as it is consistent.
One gripe I have is the placement of && and || at the end of the line.
But, of course, we can spend eternity to hash this out. :-)

As long as we are sure of what the reliable way of running |mach
clang-format| locally, I will be fine.
(I use outside the source tree object directory.)

TIA

On 2020-06-16 19:38, ISHIKAWA,chiaki wrote:

I think so.

Indeed the comm-central .clang-format hasn't always taken affect - it
will be nice not to have to deal with that anymore!

Things will now "just work", like it does for mozilla-central.

Agreed consistency will be nice!

 -Magnus

On 17/06/20 4:38 am, ISHIKAWA,chiaki wrote:

Exactly. clang-format searches upward to find the next .clang-format, so
we'll just be using the M-C one directly.

Yes, I think that's https://bugzilla.mozilla.org/show_bug.cgi?id=1575449

Yes.

No. It'll find the M-C one in the directory above.

All these tests are javascript, which isn't touched by clang-format.

Yes. He did all the heavy lifting. This is just the last bit, and much
simpler (and less disruptive - it generally won't change the number of
lines, just tweak things within a line).

Yes. The process is essentially:

delete comm/.clang-format, then:

./mach clang-format -p comm/calendar/base
./mach clang-format -p comm/common
./mach clang-format -p comm/ldap/xpcom
./mach clang-format -p comm/mail
./mach clang-format -p comm/mailnews

(so no third_party, no libical, and no ldap c-sdk... etc).
I'm embarrassed to say that I'd missed seeing .clang-format-ignore, but
I'll sort one out for our excluded paths.

Yep - we're just removing our rules in favour of the the existing M-C rules.

Sure thing - a debate for another thread.
Myself, I feel we should be making much more use of the "slide" operator
for ranges, eg:

int x=10;
while (x --


\

printf("%d ",x);

}

output:
9 8 7 6 5 4 3 2 1 0

:-)

(from https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c)

BenC.

Thank you for the clarification.

On 2020/06/18 15:10, Ben Campbell wrote:

...

So the formatting works even if we are using out of tree OBJ directory?
Well, we will find out.

(I am using out of OBJ directory...)

I see. I thought this may be used by java formatter as well.

Here, I think we can simply format ldap/c-sdk.: it is orphaned code and
I believe it has already been reformatted by Jorg.

Thank you again for the clarification.

operator for ranges, eg:

Oh, people have some fun. :-)

The following is totally unrelated to the original post.
On my PC running Japanese Windows 10, due to some localization magic
(and font set up for preferred locale and font file selection), the
screen image of the range operator code looks as in the attached image.
(The left is Ben's code in the original post I received.
The right figure is the one I began responding to Ben's post and I think
it uses Japanese JIS code.)
Problem is JIS code uses the same ASCII numbering of alphanumerical
codes and other symbols in principle, except that backslash character
code is used for Japanese YEN currency symbol. This is why the code
looks funny in my response on my screen.
So this slide operator won't fly in Japan (or whoever tries the clever
hack for the operator has to explain what was the original intention to
some Japanese desktop users and having to explain the hack loses the charm.

For that matter, the use of backslash for file path separator in MS-DOS
and subsequently in Windows is a constant source of visual pain for
Japanese programmers, who need to cope with Japanese character code. I
recall having a tough time to explain WHY the backslash in K&R C book
transformed in Japanese Yen currency mark to an editor of a publishing
house. Oh well, I digress.

Chiaki

On 19/06/20 2:55 am, ISHIKAWA,chiaki wrote:

Ahh, it's likely you'll still be hit by
https://bugzilla.mozilla.org/show_bug.cgi?id=1575449

Roughly: mach clang-format works by copying files to the tmp directory
(usually under obj-$PLATFORM/) before running clang-format
In M-C, for in-tree builds, this is fine because obj-$PLATFORM/ is
inside the main directory, and so the .clang-format file is found.
It doesn't work for C-C because it can't see .clang-format inside comm.

So, for out-of-tree builds (assuming the tmp dir is also out-of-tree),
you'll still to work around 1575449 by manually copying the
.clang-format file from M-C.

Hope that makes sense!

Heh - ask me some time about my plan to replace PDF and Word docs with
custom Pacman romsets ;-)

Ouch! ASCII has a lot to answer for. I seem to recall that some nordic
variants repurposed the curly braces '{' '}' as accented letters, which
must have made C a really fun language...

Ben.

On 16/06/20 3:32 pm, Ben Campbell wrote:

And just to follow up - the reformatting has just landed.

Ben.