<html 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:"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;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
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-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:391972704;
mso-list-type:hybrid;
mso-list-template-ids:-1377679346 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I’m sure the reference to LLVM 7 is out of date. I’m pretty sure that the devs keep up with what’s in phabricator. I’ll let other comment.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Why three?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">For code that interacts with MLIR, follow the MLIR rules.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">For code that interacts with LLVM, follow the LLVM rules.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">The front end, which also uses clang format, use the front-end rules, as described in the doc directory.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I won’t advocate for more formatting rules, but one could imagine the runtime following the guidelines of libcxx, e.g.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All in all, in the llvm-project tree, there seem to be 16 distinct .clang-format files (and 36 in all, but there are duplicates).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Johannes Doerfert <johannesdoerfert@gmail.com><br>
<b>Date: </b>Friday, April 2, 2021 at 9:30 AM<br>
<b>To: </b>Steve Scalpone <sscalpone@nvidia.com>, flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [flang-dev] Flang Coding Style<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">External email: Use caution opening links or attachments<br>
<br>
<br>
On 4/2/21 10:40 AM, Steve Scalpone wrote:<br>
> Hi Johannes,<br>
><br>
> I believe every file committed to flang runs through clang-format. There are three formats being used. The front-end files use the llvm style with some modifications. The files related to MLIR follow the MLIR style. And the files closest to LLVM follow
the LLVM style. This all seems reasonable to me.<br>
The webpage say "clang format of llvm 7" which is not what phabricator<br>
runs and not what we should announce as style guide.<br>
<br>
Three formats doesn't strike me as reasonable. What is the benefit over<br>
two, or one, either would make reviews and code writing easier.<br>
To play devils advocate, why stop at three, every folder could have a<br>
distinct style, where do we draw the line?<br>
<br>
Note that this is not only about clang format here but also naming and<br>
other things (some of which clang-tidy would flag).<br>
<br>
<br>
><br>
> There was a huge file-renaming pass done over the code before the initial merge. Do you have an example that doesn't follow the convention?<br>
<br>
I just run:<br>
for folder in {llvm,mlir,clang,flang}; do echo -n "Folder $folder,<br>
lower case:"; find $folder/lib -name '[a-z]*.cpp' | wc -l; echo -n<br>
" upper case: "; find $folder/lib -name '[A-Z]*.cpp' | wc<br>
-l; done<br>
<br>
Folder llvm, lower case:6<br>
upper case: 2226<br>
Folder mlir, lower case:0<br>
upper case: 381<br>
Folder clang, lower case:0<br>
upper case: 758<br>
Folder flang, lower case:97<br>
upper case: 36<br>
<br>
So llvm, mlir, and clang have basically no files starting with a lower<br>
case letter, flang has a 3:1 ratio of them.<br>
Note that this is only checking /lib, other places need to be checked too.<br>
<br>
Similarly, the advocated use of `-` (over `_`) neither is really used<br>
outside of flang:<br>
<br>
Folder llvm, # of '_' uses:7<br>
# of '-' uses: 0<br>
Folder mlir, # of '_' uses:0<br>
# of '-' uses: 0<br>
Folder clang, # of '_' uses:0<br>
# of '-' uses: 4<br>
Folder flang, # of '_' uses:0<br>
# of '-' uses: 64<br>
<br>
So these are obvious differences when it comes to naming conventions, I<br>
did not spend too much time on it though.<br>
<br>
<br>
><br>
> The compilation slowness may be related to heavy use of std::variant. I'm not trying to be difficult here but perhaps you can bring up the compilation speed issue with cfe? Michael Kruse measured the time required to compile flang with gcc, vc++, and clang;
my recollection is that clang was slowest of the batch.<br>
<br>
We can "blame" clang for being slow and even try to improve it, that<br>
doesn't change the fact that the "suggestions" online are in direct<br>
contradiction to common practices across the project. It happens that<br>
these "suggestion" are also a likely candidate for the build time<br>
issues and a reasonable reaction would be to backtrack and follow the<br>
path plotted by the rest of LLVM to avoid them.<br>
<br>
~ Johannes<br>
<br>
<br>
><br>
> - Steve<br>
><br>
> On 4/1/21, 1:51 PM, "flang-dev on behalf of Johannes Doerfert via flang-dev" <flang-dev-bounces@lists.llvm.org on behalf of flang-dev@lists.llvm.org> wrote:<br>
><br>
> External email: Use caution opening links or attachments<br>
><br>
> I was struggling with myself because I don't want to derail the current<br>
> progress,<br>
> however, I figured it is still worth pointing this out (again), the<br>
> earlier the better.<br>
><br>
> ---<br>
><br>
> I read over Flang patches regularly and I got more and more annoyed by<br>
> the coding style. I don't<br>
> know who designed it and why but it causes actual burden for people that<br>
> otherwise work with the LLVM style.<br>
><br>
> I am aware this was discussed before but I vaguely remember we wanted to<br>
> get closer to LLVM style<br>
> and I am worried that goal has been forgotten by now.<br>
><br>
> My initial suggestion is to change the online style guide, highlighted<br>
> with *ABC*.<br>
><br>
> * Use /clang-format/ from llvm *trunk* on all C++ source and header<br>
> files before every merge to master. All code layout should be<br>
> determined by means of clang-format.<br>
> * *Where LLVM’s C++ style guide<br>
> <<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FCodingStandards.html%23style-issues&data=04%7C01%7Csscalpone%40nvidia.com%7Cb8dde9c781284acc872f08d8f5f49418%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637529778094599975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=H8gz%2F8YG6cxJ2mJhA0eETSBRYuVQQ2i3%2B8CuJhQwer4%3D&reserved=0">https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FCodingStandards.html%23style-issues&data=04%7C01%7Csscalpone%40nvidia.com%7Cb8dde9c781284acc872f08d8f5f49418%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637529778094599975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=H8gz%2F8YG6cxJ2mJhA0eETSBRYuVQQ2i3%2B8CuJhQwer4%3D&reserved=0</a>>
is clear<br>
> on usage, follow it.*<br>
> * *Otherwise,* where a clear precedent exists in the project, follow it.<br>
><br>
> Filenames should follow the LLVM naming style.<br>
><br>
> The "Overall design preferences" should be rewritten. The content is not<br>
> only add odds with existing<br>
> practices in LLVM (& MLIR, OpenACC, OpenMP, ...) but probably also one<br>
> of the reasons we have to discuss<br>
> Flang compile times regularly. I mean, I love really crafty C++<br>
> meta-programming solutions as much as the next<br>
> person but we should rethink the trade-off we are advocating for.<br>
><br>
> Once we redefine the rules we can adopt the LLVM style piece by piece or<br>
> in one big swoop. Either way, let's<br>
> actually follow through on those discussions we had Feb 2020.<br>
><br>
> ~ Johannes<br>
><br>
><br>
> --<br>
> ───────────────────<br>
> <span style="font-family:"Cambria Math",serif">∽</span> Johannes (he/his)<br>
><br>
> _______________________________________________<br>
> flang-dev mailing list<br>
> flang-dev@lists.llvm.org<br>
> <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fflang-dev&data=04%7C01%7Csscalpone%40nvidia.com%7Cb8dde9c781284acc872f08d8f5f49418%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637529778094609973%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=34FutzNtRBYhtNXwn2G%2FTvbgaekWMAHjXVCHelLZwlw%3D&reserved=0">
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fflang-dev&data=04%7C01%7Csscalpone%40nvidia.com%7Cb8dde9c781284acc872f08d8f5f49418%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637529778094609973%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=34FutzNtRBYhtNXwn2G%2FTvbgaekWMAHjXVCHelLZwlw%3D&reserved=0</a><br>
><o:p></o:p></p>
</div>
</div>
</body>
</html>