This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] clang-format (NFC)
ClosedPublic

Authored by aheejin on Aug 29 2018, 11:33 AM.

Diff Detail

Event Timeline

aheejin created this revision.Aug 29 2018, 11:33 AM

The LLVM coding standards say "we explicitly do not want patches that do large-scale reformatting of existing code". They suggest that reformatting should be done to address specific readability issues or to prepare an area for subsequent changes.

Yes I read that, but this patch is just hundreds of lines, and the clang patch (D51448) and the lld patch (D51449) are even smaller, which are less than 100 lines. I was not sure if this qualifies for a 'large-scale' patch, so I thought I would upload it and hear people's opinions.

aheejin added a comment.EditedAug 29 2018, 12:47 PM

Also, among the hundreds of lines in this patch, it looks more than half of them are from simple switch-case differences, when people prefer

case SOMETHING: break;

over

case SOMETHING:
  break;

My reading of the intention behind the policy is that we want to avoid patches that make it hard to find who owns some code or that unnecessarily trod on someone else's code uninvited. That passage seems like it is meant for people who don't like LLVM's style and would want to change everything at once. Since this change only affects the WebAssembly backend and increases conformance with LLVM style, I think it is a good idea.

If we want to make concerted progress toward full clang-formattedness (I like the idea in general, but opinions sometimes differ on the value of that) we could do it one file at a time, to be landed before making some change to that file. That would be a sort of compromise; it would keep the changes small and manageable, but it would be a larger granularity and scope than what you'd strictly need if you were going to make a small change or just work on one component (which would mean faster progress).

If nothing else though, here's your reminder that 'git clang-format' is a great tool and can automatically format just your diff against master. So that's an easy way to ensure we at least have things formatted as we check them in.

I guess I don't have a strong opinion here. The code is already pretty close to clang-format's interpretation of LLVM style, so looking at the actual diffs you're right that it doesn't seem to be a big change. Changes like those in WebAssemblyLowerBrUnless.cpp are a little unfortunate, but tolerable.

The best solution would be if the LLVM project had a pre-submit clang-format hook, so this never needs to be done manually ever again.
I'm suprised as the authors of clang-format that they don't have this :)

I'm totally OK with not landing this if there are any objections. :) But if we are ever gonna pursue clang-formattedness on wasm backend, I think doing it in a single CL that everyone is aware of makes it actually easier than having dozens of reformatting CLs when you trace history back using git blame or something. We can of course not do this, which is totally fine.

Ping. Does anyone have more opinions on this? Do you think I can land this or this is not a good idea?

I'm cool either way.

dschuff accepted this revision.Sep 4 2018, 2:49 PM

I took another look at the diff, and it does seem like we are fairly close already. I agree that some of the changes to the switch statements aren't great, but on balance it's probably worthwhile to be able to just run clang-format and accept whatever it generates. I think we can go ahead and land this.

This revision is now accepted and ready to land.Sep 4 2018, 2:49 PM

On one hand, clang-format -style=LLVM really isn't the one exclusive formatting style of LLVM. CodingStandards.rst repeatedly emphasizes this. When we're working in LLVM outside of wasm-specific code, we need to respect the existing code formatting which isn't always clang-formatted, or locally reformat it as needed when making changes, so it's not a bad idea for us to get used to working that way anyway. And we accept patches that aren't clang-formatted.

At the same time, it's just formatting, and the changes here are pretty minor overall, and the svn blame issue is ultimately just an occasional minor nuisance, so if you feel strongly about this, feel free to land it.

@sunfish Thanks. I agree that we have to respect the original file's style when we make changes to existing files, especially those that are not exclusive to wasm. But in these wasm-only files we didn't particularly have another style that deviates from LLVM, other than a few places of switch-cases. So I thought it might be possible to ensure clang-formattedness for wasm-exclusive code for now and we can recommend that for future committers as well.

Thank you everyone for comments! I'll land this then. :)

This revision was automatically updated to reflect the committed changes.