================
@@ -294,6 +294,16 @@ ANALYZER_OPTION(
bool, ShouldUnrollLoops, "unroll-loops",
"Whether the analysis should try to unroll loops with known bounds.",
false)
+ANALYZER_OPTION(
+ bool, ShouldAssumeOneIteration, "assume-one-iteration",
+ "Whether the analyzer should always assume at least one iteration in "
+ "loops where the loop condition is opaque (i.e. the analyzer cannot "
+ "determine if it's true or false). Setting this to true eliminates some "
+ "false positives (where e.g. a structure is nonempty, but the analyzer "
+ "does not notice this); but it also eliminates some true positives (e.g. "
+ "cases where a structure can be empty and this causes buggy behavior).",
----------------
NagyDonat wrote:
> It could be mentined that this option interacts with analyzer option
> 'eagerly-assume'.
It's just a bug -- not an undocumented feature :upside_down_face: .
The _implementation_ of my change needs to heavily interact with
`eagerly-assume` but I'm trying to reimplement the same behavior with and
without it. There are some contrived corner cases where enabling or disabling
`eagerly-assume` changes the behavior of this `assume-one-iteration` logic, but
I wasn't able to construct an example that could plausibly appear in real-world
code, so I don't think that we need to document these theoretical buggy cases.
https://github.com/llvm/llvm-project/pull/125494
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
