[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