zygoloid wrote: > +1 for this, it will be the 95%/5% rule, you might think all cases of > (identifier) is a cast, but I'm pretty sure it won't be
Specifically, what I suggested was: when disambiguating whether `(identifier)&...` or `(identifier)*...` is a cast vs a multiplication or bitwise and (that is, the case that the previous patch changed, resulting in the regression we're trying to fix), treat it as a cast unless `identifier` is a macro parameter name. I think that will be right >99% of the time. And even when clang-format gets it wrong, the programmer can fix that by removing the redundant and non-idiomatic parentheses around the identifier. > I'm with @owenca on this, this patch will move us closer, meaning users don't > need to add common types to TypeNames As I said before, I think special-casing these typedefs is a good thing - it's reasonable for clang-format to assume they're type names. But I don't think this moves us much closer to fixing the bug, because most casts won't be to one of these typedefs. I do wonder, though -- there's a lot of churn in this patch adding and wiring through a new parameter. Can the `TypeNames` mechanism be prepopulated with this list of types instead? https://github.com/llvm/llvm-project/pull/83709 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
