<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 20, 2021 at 12:03 AM Andy Wingo <<a href="mailto:wingo@igalia.com">wingo@igalia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Just a couple cents from a relative newcomer to LLVM, please take them<br>
with their appropriate worth ;)<br>
<br>
On Thu 19 Aug 2021 21:21, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> It's pretty important to me that we don't make it easier to create<br>
> more divergence in naming conventions - creating another project that<br>
> diverges from LLVM's naming conventions/creates more naming<br>
> inconsistency seems like a loss to me. So until there's some buy-in<br>
> for a desired future direction, I think new projects should adhere to<br>
> the existing convention.<br>
<br>
FWIW I found when switching between lld and llvm to be jarring -- I had<br>
to know that there were two coding conventions, and that one was<br>
documented and one was not.  It wasted a bit of reviewer time pointing<br>
out these issues (though of course the tools helped).<br>
<br>
> I don't think that future direction must include a way to cleanup LLVM<br>
> - as Chris Lattner said, maybe it is something like "Even if the<br>
> community does not have the appetite to do a huge scale renaming of<br>
> all the things in LLVM, it would be interesting to carve out an<br>
> exception for new code being written, refactored, or potentially for<br>
> use in new subprojects." - though I think that's a choice we should<br>
> all make together (doesn't require it to be unanimous) and<br>
> carefully. That does produce the inconsistent-with-LLVM-core issue I'm<br>
> concerned about, but maybe with a path forward to consistency. Might<br>
> be worth talking about whether people would be comfortable with more<br>
> active cleanup - not necessarily one huge renaming, but be willing to<br>
> accept patches that rename things without necessarily being pieces of<br>
> code being actively refactored for other reasons. That'd help<br>
> alleviate the "now we're going to have N different conventions based<br>
> on when a given subproject was introduced", which increases friction<br>
> when moving between subprojects (as zturner pointed out in some of the<br>
> discussion/code review of style changes proposed previously). - Dave<br>
<br>
Here again I found problems when switching to clang -- you end up with<br>
different naming conventions per file (what is the convention for<br>
<a href="https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ConstantEmitter.h" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/ConstantEmitter.h</a><br>
?  When making a patch, which convention to use?) and sometimes even<br>
within a file (consider<br>
<a href="https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L4819-L4831" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L4819-L4831</a><br>
vs<br>
<a href="https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L1484-L1491" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.h#L1484-L1491</a>).<br>
So when making a patch I have to know not only the coding convention but<br>
also the direction that things are supposed to be going, and there does<br>
not appear to be project-wide consensus on that.<br>
<br>
Also just FWIW, when I was working on Firefox they changed coding<br>
conventions but did so with a big bang switch.  I found it much easier<br>
to navigate -- the situation was at all times clear to me.<br></blockquote><div><br></div><div>Any idea what, if anything, they did to address issues of revision history navigation, helping people update their outstanding patches over the transition, etc?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>From my limited perspective It Would Be Good™ if llvm would end up in a<br>
situation where the coding conventions were always enforced -- the<br>
situation in clang is perhaps the least desirable one.  And bonus if it<br>
is the same convention across the project :)<br>
<br>
Regards,<br>
<br>
Andy<br>
</blockquote></div></div>