[clang] [clang-format] Fix a bug in annotating angles containing FatArrow (PR #108671)

[kadir çetinkaya via cfe-commits]

================
@@ -243,14 +244,16 @@ class AnnotatingParser {
       // operator that was misinterpreted because we are parsing template
       // parameters.
       // FIXME: This is getting out of hand, write a decent parser.
-      if (InExpr && !Line.startsWith(tok::kw_template) &&
+      if (InExpr && !SeenFatArrow && !Line.startsWith(tok::kw_template) &&
           Prev.is(TT_BinaryOperator)) {
         const auto Precedence = Prev.getPrecedence();
         if (Precedence > prec::Conditional && Precedence < prec::Relational)
           return false;
       }
       if (Prev.isOneOf(tok::question, tok::colon) && !Style.isProto())
         SeenTernaryOperator = true;
+      else if (Prev.is(TT_FatArrow))
----------------
kadircet wrote:

sorry I wasn't saying that `FixedInt<N | M>(foo);` is clearly a template argument, it's definitely ambiguous in absence of name-resolution and there isn't much clang-format can do here.

this kind of backward incompatible changes are making it harder to update clang-format to newer versions in large codebases. as clang-format right now is trading off one set of false-formatting with other. hence my understanding for the project has been to `stick with existing formatting, if we're heuristically detecting some patterns. so that behavior on existing formatted-code doesn't regress.` maybe that understanding has changed over time, or wasn't there at all. But this bug and requested changes in your PR was solely made with that assumption (as many others I've been filing over the past years).

hence I am not expecting a "fix" for the issue here, but I guess a narrowed down version of [other patch](https://github.com/llvm/llvm-project/commit/73c961a3345c697f40e2148318f34f5f347701c1), where it actually preserves behavior with old clang-format in uncertain cases.

https://github.com/llvm/llvm-project/pull/108671