gamesh411 wrote: > Have you checked if any of the checkBind users used an `isa` or `dyncast` as > a proxy to determine if its an assignment expression or an initialization? I > suspect there could have been cases where they tried to use this as a proxy, > that we could not substitute to this explicit flag instead.
I searched for patterns where other checkers might be using isa/dyn_cast on statement types (like DeclStmt, BinaryOperator) as a proxy to determine if something is an assignment vs initialization. I found only in any of the checkBind implementations. The checkers that do use dyn_cast<BinaryOperator> and dyn_cast<DeclStmt> are using them for different purposes - such as extracting the right-hand side expression for better error messages, getting the initialization expression from variable declarations, or checking for ARC zero-initialized locals. None of them use statement type checking as a proxy to determine if something should be skipped or handled differently based on whether it's an assignment vs initialisation. This flag solves the problem of the StoreToImmutable checker in a way that fits the core logic we want to use, and is already information available in the engine itself; this is the biggest pro for its existence. It could also help new checkers, but that is just speculation. I did not investigate in detail whether this new flag could be used in the existing checkers, but I suspect that would require some moderate rethinking of their logic, even in the cases where it is possible. So I would not go that route just for the sake of using this new flag. The place most fitting for using this is inside UndefinedAssignmentChecker, but even there, the current flow of implementation does not benefit from https://github.com/llvm/llvm-project/pull/152137 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
