<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>A couple of points for consideration. Fair warning, I have not
read the full discussion down thread, these might have already
been raised.</p>
<ol>
<li>File granularity is the wrong scope to be thinking in. A file
which is 99% clang formatted is much better than one which is 1%
clang-formatted. Any system which tries to automatically
generate patches should think in terms of scopes (functions,
classes), and propose changes based on the age of that code, not
the age of the file.</li>
<li>Formatting changes (of this particular proposed type) should
definitely be reviewed. This allows different areas of the code
base to move at different paces based on the relative importance
assigned by the knowledgeable reviewers. <br>
</li>
<ol>
<li>The rate of submission should be strictly rate limited on a
per reviewer basis. (i.e. 100 outstanding reviews w/100
distinct reviewers is very different than hitting one person
with 100 reviews)</li>
<li>To make this practical, someone needs to own the rebase and
land after approval process. This could be automated (github
PR anyone), but is not optional. The workflow for reviewer
must be "approve and never think about again".</li>
<li>The option to reject permanently a proposed change must be a
first class outcome. This can be done either by using
explicit markers in code, or by maintaining an external
"no-format" list. Having this list public - since there's
likely to be disagreement about items on it - is good.</li>
<li>Someone must also commit to shepard the reviews. Objections
to formatting must be addressed proactively. (e.g. changes
made to format config file) not simply yelled into the the
ether. <br>
</li>
</ol>
<li>The goal of such a system should not be to test clang-format.
If you want a test corpus, create one in a fork. The only
motivation we should consider is if it improves the development
productivity of our engineers or the quality of our code base.
(I happen to think it's likely to do both.)<br>
</li>
</ol>
<p>Of, and in case it's not obvious, I generally think that a well
managed system is valuable here. If someone wants to sign up to
drive the non-trivial amount of work required here, awesome!<br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 6/28/20 8:30 AM, MyDeveloper Day via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD7AeN7dwdEZhFo1zPD5Cnc6xsM7DqzaJ=rg=3UfA-CKNFotZQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<p
style="margin-top:0px;font-family:Helvetica,Arial,sans-serif;font-size:15.008px">(Copying
from Discourse)</p>
<p
style="margin-top:0px;font-family:Helvetica,Arial,sans-serif;font-size:15.008px">All</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">A
couple of months ago I added the following page documentation <a
href="http://clang.llvm.org/docs/ClangFormattedStatus.html"
rel="nofollow noopener"
style="background:transparent;color:rgb(0,136,204);text-decoration-line:none"
moz-do-not-send="true">Clang-Formatted-Status</a> to track
the status of “How Much” clang-formatted the </p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">LLVM/Clang
project is.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">I’m
a contributor to clang-format and would like to see LLVM 100%
clang formatted so we can use LLVM as a massive test-suite for
clang-format when we make changes.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">In
the last couple of months since we added this page the % has
gone up by ~4% and this is likely in most part of either: a
mention in LLVM-Weekly, the premerge checks or perhaps some
recent clang-format efforts by individuals. This is fantastic
and every directory that gets to 100% increase the directories
that I can run against to check against.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">However,
it recently twigged to me that files that don’t change very
often are never going to be 100% clang-formatted simply by
virtue of clang-formatting all new changes.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">So
I 100% understand this kind of topic comes up from time to
time and I understand that we don’t want to automatically
clang-format the entire tree as this can disrupt peoples
downstream forks, especially where they actively have code
inflight.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">But
I wonder if we could have a general rule that said a [NFC]
clang-format change could be made on ANY file that had NOT
been changed in a 6/12 months period? I believe this process
could be automated at least in a semi-automatic way. Once
complete the pre-merge checks should maintain the current
status.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">This
would drive the goal of completely clang-formatted source
tree, without the disruption to current active areas.</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">Any
thoughts?</p>
<p
style="font-family:Helvetica,Arial,sans-serif;font-size:15.008px">MyDeveloperDay</p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>