<div dir="ltr">Really thank you to everyone for the comments,on the RFC I thought I'd try to keep quiet on the RFC so as not to appear overly pressing my agenda, I'm super glad that we have got to a nice consensus, thank you to those that summarized it.<div><br></div><div>We'll definitely take care, and we can introduce something into the documentation at some point to highlight the existing breaking changes (sort includes, namespace commenter etc...) and use this going forward.</div><div><br></div><div>On the point of "Version to Version" breaking, there doesn't feel like something that can be solved easily other than us simply not touching the code and not fixing bugs. We get a relatively good stream of people</div><div>logging issues in the bug tracker, and frankly we don't have enough people working through them. (I personally can't keep up so I tend cherry pick! depending on my availability.)</div><div><br></div><div>For the clang-format team the way to try and minimise the changes between versions is IMHO to be quite strict about NOT changing any existing tests, and I to push back on reviews that do unless there is good</div><div>reason. (i.e. the test was previously wrong)</div><div><br></div><div> But I  still causing changes version to version mainly because we are fixing bugs rather than adding new features. Recent improvement to make clang-format handle K&R code better, means we now identify functions better, </div><div>The consequence of which is in the large code base that I manage this identified 100s of cases where "BreakAfterReturn" was incorrectly formated previously. Also recent changes to AfterEnum to make it more correct in enum detection</div><div>will likely find lots of places where enum was/n't breaking correctly.</div><div><br></div><div>In my view this issue is tangential to what we want to do with being able to modify the token stream, which we'd hope to keep completely seperate and not have any impact if turned off.</div><div><br></div><div>Some asked what was being proposed, and the review I was working on is for clang-format ensuring consistent "Left/Right" const/volatile placement. (<a href="https://reviews.llvm.org/D69764">https://reviews.llvm.org/D69764</a>) Running this on LLVM shows a couple of places where even we are not consistent, please note this is still WIP.</div><div><br></div><div>MyDeveloperDay</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 27, 2021 at 7:33 PM Manuel Klimek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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"><div dir="ltr"><div dir="ltr">On Fri, Aug 27, 2021 at 4:08 PM Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, 27 Aug 2021 at 15:03, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * Backwards compatibility is pursued, but can be broken in case of clear bugs<br></blockquote><div><br></div><div>Which I think is also tangential to the current RFC, and IMO should be treated in a separate discussion if necessary (this is a fundamental problem with how clang-format is designed).</div></div></div></blockquote><div><br></div><div>Is this a fundamental problem with the code structure and maintainability or with the mindset of the main developers?</div></div></div></blockquote><div><br></div><div>It's the algorithm - clang-format is a numerical optimizer of "beauty" - any small changes can lead to the numerical outputs changing slightly, which then leads to slight diffs in how code is formatted where two options were previously considered very "similarly beautiful". It's not happening super often, but it does happen.</div><div><br></div><div>I agree that we shouldn't introduce changes to formatting without good reasons, but we can't restrict changes only to bug fixes - new features can introduce changes, too.</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>