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

[Owen Pan 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))
----------------
owenca wrote:

> 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.

This patch IMO *is* a narrowed down version of the other patch #100980, which fixed a real regression #100300 caused by yet another patch #96801, which in turn was an attempt at fixing a real bug #81385.

In your [reply](https://github.com/llvm/llvm-project/pull/108671#discussion_r1762725421) above, it doesn't seem that your C++ example `return FixedInt<N | M>(foo);` is from an existing codebase. The fact that it happened to get formatted that way before doesn't necessarily mean that we should always format another similar pattern e.g. `return Foo < A || B > (C ^ D);` the same way, especially if the latter is much more likely.

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