<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I’m in favor of this because, like you said, unless we do something like this, we’ll never get there. Frankly, I think the inactive period should be much shorter. I would even go so far as to say something like 1 month of inactivity. This
 codebase is under heavy development, so any code under active development will likely be touched in a 1 month period. 6-12 months will only catch the truly stable code, but any code that only gets minimal changes will never reach 100% coverage.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would also like to see a threshold (maybe on a per-file or per-subfolder level of granularity) where once the coverage gets over the threshold, we just “rip the band-aid off” and clang-format everything. Suppose we set the threshold at
 90%, and Foo.cpp is over 90% formatted, we just format the entire file and be done with it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m sympathetic to the argument that these sorts of change make managing downstreams more difficult, I maintain one myself.  However, I would argue that finishing the formatting as fast as possible will reduce downstream pain because after
 the codebase is completely formatted, it’ll just be done and there will be no more formatting churn. As it stands, we constantly have to deal with formatting changes because there’s always new ones.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">   Christopher Tetreault<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>MyDeveloper Day via llvm-dev<br>
<b>Sent:</b> Sunday, June 28, 2020 8:31 AM<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] [llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p style="margin-top:0in"><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">(Copying from Discourse)<o:p></o:p></span></p>
<p style="margin-top:0in"><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">All<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">A couple of months ago I added the following page documentation <a href="http://clang.llvm.org/docs/ClangFormattedStatus.html"><span style="color:#0088CC">Clang-Formatted-Status</span></a> to
 track the status of “How Much” clang-formatted the <o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">LLVM/Clang project is.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">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.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">This would drive the goal of completely clang-formatted source tree, without the disruption to current active areas.<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">Any thoughts?<o:p></o:p></span></p>
<p><span style="font-size:11.5pt;font-family:"Helvetica",sans-serif">MyDeveloperDay<o:p></o:p></span></p>
</div>
</div>
</body>
</html>