[PATCH] D39363: [clang-tidy] Correctly classify constant arrays and constant strings as constants when checking identifiers naming

berenm added a comment. Yes, please could you commit it for me? Thanks! Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D39363 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-

[PATCH] D39363: [clang-tidy] Correctly classify constant arrays and constant strings as constants when checking identifiers naming

berenm updated this revision to Diff 126177. berenm added a comment. Rebase patch on upstream HEAD Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D39363 Files: clang-tidy/readability/IdentifierNamingCheck.cpp test/clang-tidy/readability-identifier-naming.cpp Index: test/cla

[PATCH] D39363: [clang-tidy] Correctly classify constant arrays and constant strings as constants when checking identifiers naming

berenm added a comment. In https://reviews.llvm.org/D39363#948134, @alexfh wrote: > Sorry for the delay. I missed this revision somehow. Please add cfe-commits > to the subscribers list so that others can chime in. No worries, I'll add it in the future. Thanks! Repository: rCTE Clang Tool

[PATCH] D39363: [clang-tidy] Correctly classify constant arrays and constant strings as constants when checking identifiers naming

berenm updated this revision to Diff 126017. berenm added a comment. Herald added a subscriber: klimek. Factor !Type.isNull() && Type.isConstQualified() condition Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D39363 Files: clang-tidy/readability/IdentifierNamingCheck.cpp te

[PATCH] D30931: [clang-tidy] added new identifier naming case type for ignoring case style

berenm added a comment. In https://reviews.llvm.org/D30931#700690, @alexfh wrote: > I understand your use case, but this patch makes the check's behavior more > confusing: having both "any case" and "ignore case" with subtle differences > in behavior seems very misleading. The problem seems to

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

berenm added a comment. Pinging @djasper There's https://reviews.llvm.org/D27651 that will conflict with this one. https://reviews.llvm.org/D21279 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinf

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and &s to the right

berenm accepted this revision. berenm added a comment. This revision is now accepted and ready to land. Awesome! Pinging @djasper https://reviews.llvm.org/D27651 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and &s to the right

berenm added a comment. Yes you are right, I believe it's happening for comma-separated declaration list. I think the algorithm tries to keep it clear that the pointer / reference marks are for each declared identifier and not part of the common type. I think that splitting the declarations fo

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and &s to the right

berenm added a comment. I'm trying to think of a scenario where *, && or & before tokens to be aligned would not indicate pointers or references, but as the alignment is only done for now on declarations and assignments, I can't find one. Maybe you could add one more test case to check Left poi