[clang] [analyzer] Enforce not making overly complicated symbols (PR #144327)
Balázs Benics via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 24 07:31:15 PDT 2025
================
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed the
+/// MaxSymbolComplexity threshold.
+/// TODO: When the MaxSymbolComplexity is reached, we should propagate the taint
+/// info to it.
+class SymbolTooComplex final : public SymbolData {
+ // Pointer to either "SymExpr" or "APSInt".
+ const void *LHS;
+ const void *RHS = nullptr; // optional
+ QualType Ty;
+ using OpKindType = std::make_unsigned_t<
+ std::common_type_t<BinaryOperatorKind, UnaryOperatorKind>>;
+ OpKindType Op = 0;
----------------
balazs-benics-sonarsource wrote:
I explored the direction of creating the overly complicated symbol, and then just wrapping that in bb82e63b88d1bd233a7895129d25d2cc3b5bc5e4. I think this is what you asked.
Note that this approach has the slight disadvantage of actually creating overly complicated symbols to wrap.
Sometimes this new symbol will have a complexity equal to max complexity, and other times well over that complexity in case we combined two max complexity symbols by a binop like `+`.
Remember, complexity is calculated by `complexity(LHS) + complexity(RHS)`.
This simplifies the code quite a bit though. Besides aesthetics, it should not change the overall behavior too much.
https://github.com/llvm/llvm-project/pull/144327
More information about the cfe-commits
mailing list