================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
