On Wed, Jun 17, 2015 at 06:57:04PM -0700, Gregory Szorc wrote: > On Wed, Jun 17, 2015 at 6:29 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > > As an experiment, we declared the coding style of rr to be "whatever > > clang-format produces with rr's .clang-format file" (which was tweaked to > > resemble Mozilla style, including an 80-char line limit). Overall I've been > > very happy with the results. Sometimes you get suboptimal linebreaking > > decisions, but that's small potatoes compared to the joy of not having to > > think about code formatting when you're reading or writing code. I'd be all > > for doing something similar in Gecko. > > > > +1 > > Assessing style compliance as == clang-format(whole file) is by far the > easiest to implement. I'd be in favor of a flag day (or set of mini flag > days) where we mass rewrite the tree with clang-format's output. > > As far as keeping things in compliance, I'm not opposed to running > clang-format on hg.mozilla.org as part of a push hook - I think it is fast > enough that it won't introduce too much latency. If that doesn't work, > Autoland could run clang-format automatically as part of landing commits. > > Mercurial now has support for server-side rebasing/rewriting during push > operations. As of this week, this is deployed on hg.mozilla.org. > Essentially you push up commits, the server changes them, and the rewritten > commits are pushed back to the client. One can imagine a world where > clang-format and similar functionality occur at push time. We could e.g. > have the MozReview repository auto format code as you submit it. Of course, > if we go all in on formatting tools, developers should have this integrated > into their local workflows so we don't need server-side assistance (it's > possible to reprogram the "save" action in many editors). But not everyone > will do this, so I reckon we need defense in depth. > > First thing is first: what are the blockers to mass rewriting > mozilla-central with clang-format's output?
There are only two real blockers: - Coming up with the right clang-format config matching our coding style. IIRC, there /are/ a couple things that clang-format can't do currently, even with a very specific config. Ideally, clang-format's bundled Mozilla style should also be updated to match that config (because it's kind of silly to have a clang-format config that starts with "BasedOnStyle: Mozilla" and has 42 tweaks). - Identifying third-party directories that should be left untouched, and that's not really hard. It might be useful to have a helper script to help with rewriting patches, because complex cases look like: - apply patch on changeset before flag day - backup patched files - update tree to flag day changeset - restore patched files - apply clang-format - update patch. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
