<div dir="ltr"><div dir="ltr">On Wed, Oct 14, 2020 at 10:17 PM Renato Golin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</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">Hi folks,<div><br></div><div>A recent issue [1] on our Github project has highlighted a problem we've been having with clang-format.</div><div><br></div><div>Basically, when using different versions of clang-format, with the same configuration files [2], we get different results (between 9 and 10).</div></div></blockquote><div>AFAIK this is in principle expected, clang-format doesn't place a high prioriy on having stable formatting results across major versions.</div><div>This is a tradeoff, requiring formatting to stay stable implies not fixing bugs.</div><div><br></div><div>In some workflows you can mitigate this by formatting/checking changed lines, which at least reduces the surface area.</div><div>But this is certainly a pain point if you want to enforce style with CI in a diverse environment.</div><div>At work, we enforce the same version of clang-format on all clients and CI.</div><div>In a JS-based package I work on, we use the <a href="https://www.npmjs.com/package/clang-format">clang-format npm package</a> to pin the version.</div><div><br></div><div>BTW, someone recently added a clang-format flag to ignore unknown keys in the config file, which will help in the distant future (when clangd-12 is the *minimum* version it's safe to assume...)</div><div><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><a href="https://github.com/microsoft/verona/blob/master/src/mlir/dialect/Typechecker.cc#L79" target="_blank">https://github.com/microsoft/verona/blob/master/src/mlir/dialect/Typechecker.cc#L79</a><br></div><div><br></div><div>clang-format-9:<br></div><div>    Rule(F f)<br>      ->Rule<<br>        typename rule_traits<decltype(&F::operator())>::Left,<br>        typename rule_traits<decltype(&F::operator())>::Right,<br>        F>;</div><div><br></div><div>clang-format-10:<br></div><div>    Rule(F f) -> Rule<<br>      typename rule_traits<decltype(&F::operator())>::Left,<br>      typename rule_traits<decltype(&F::operator())>::Right,<br>      F>;<br></div></div></blockquote><div>This looks like a bugfix to me. I think deduction guides were basically unsupported and broken in 9.</div><div>If I'm right about that, there's certainly no option to restore the old broken behavior.</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"><div dir="ltr"><div></div><div><br></div><div><a href="https://github.com/microsoft/verona/blob/master/src/mlir/dialect/VeronaTypes.cc#L487" target="_blank">https://github.com/microsoft/verona/blob/master/src/mlir/dialect/VeronaTypes.cc#L487</a><br></div><div><br></div><div>clang-format-9:<br></div><div>      return {MeetType::get(ctx, readElements),<br>              JoinType::get(ctx, writeElements)};</div><div><br></div><div>clang-format-10:<br></div><div>      return {<br>        MeetType::get(ctx, readElements), JoinType::get(ctx, writeElements)};<br></div></div></blockquote><div>Less clear to me what's going on here, but I also suspect a bugfix.</div><div>The docs say "Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place.".</div><div>The clang-format-10 formatting is equivalent to how both clang-format-9 and 10 format `return x(MeetType::get(...), JoinType::get(...));`.</div></div></div>