[clang] [analyzer] Fix zext assertion failure in loop unrolling (PR #121203)

[via cfe-commits]

================
@@ -283,10 +283,12 @@ static bool shouldCompletelyUnroll(const Stmt *LoopStmt, ASTContext &ASTCtx,
   llvm::APInt InitNum =
       Matches[0].getNodeAs<IntegerLiteral>("initNum")->getValue();
   auto CondOp = Matches[0].getNodeAs<BinaryOperator>("conditionOperator");
-  if (InitNum.getBitWidth() != BoundNum.getBitWidth()) {
-    InitNum = InitNum.zext(BoundNum.getBitWidth());
-    BoundNum = BoundNum.zext(InitNum.getBitWidth());
-  }
+  unsigned MaxWidth = std::max(InitNum.getBitWidth(), BoundNum.getBitWidth());
----------------
shenjunjiekoda wrote:

Thank you for your thoughtful feedback!

In Clang's AST, `IntegerLiteral` represents unsigned integer values. To represent a literal like `-1`, the AST typically uses a combination of `UnaryOperator(-)` and `IntegerLiteral`.

Regarding zero extension (`zext`), it is semantically correct here because `APInt` (the return type of `IntegerLiteral::getValue()`) inherently represents unsigned values. 

I considered whether tools like `APSIntType` could simplify this logic. However, since this operation deals specifically with unsigned integers (APInt), using APSIntType would introduce unnecessary complexity for signed semantics, which is not required here. The current use of APInt ensures precision and correctness.

On whether we could switch to `int64`, I think converting to int64 might not simplify the code too much.

Let me know if further clarification or adjustments are needed!

https://github.com/llvm/llvm-project/pull/121203