================
@@ -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))
----------------
nico wrote:
When we update clang-format in chromium, we format a chunk of the codebase with
old and new clang-format versions and look at the diff. We also ran into this
regression:
https://chromium-review.googlesource.com/c/chromium/src/+/6174847/1..2/base/allocator/partition_allocator/src/partition_alloc/shim/allocator_shim_default_dispatch_to_partition_alloc.cc
We reported #123144 which pointed us to here.
While it's true that `a<b | c>(d)` could be `a < b | c > (d)`, using `|`
(instead of `||`) with comparisons and using parenthesized one-element
expressions seems less likely than this being a template function call with
explicit template arguments that are a bitwise or, right? Maybe the heuristics
could be tweaked to pick the template personality of <> when that seems "more
likely"?
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
