=?utf-8?q?Donát?= Nagy <[email protected]>,
=?utf-8?q?Donát?= Nagy <[email protected]>,
=?utf-8?q?Donát?= Nagy <[email protected]>,
=?utf-8?q?Donát?= Nagy <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
================
@@ -299,13 +299,12 @@ ANALYZER_OPTION(
ANALYZER_OPTION(
bool, ShouldEagerlyAssume, "eagerly-assume",
- "Whether we should eagerly assume evaluations of conditionals, thus, "
- "bifurcating the path. This indicates how the engine should handle "
- "expressions such as: 'x = (y != 0)'. When this is true then the "
- "subexpression 'y != 0' will be eagerly assumed to be true or false, thus "
- "evaluating it to the integers 0 or 1 respectively. The upside is that "
- "this can increase analysis precision until we have a better way to lazily
"
- "evaluate such logic. The downside is that it eagerly bifurcates paths.",
+ "If this is enabled (the default behavior), when the analyzer encounters "
+ "a comparison operator or logical negation, it immediately splits the "
----------------
steakhal wrote:
I don't get your response here. I thought we want to update the doc comments
here to reflect what the function does. I raised that I think implicit
conversions also trigger this code path (and do eager splits). Consequently, I
figured that this behavior should be also mentioned here and now.
If bool conversions don't trigger this function, then of course my suggestion
is void.
I didn't mean to suggest function changes by my comment.
About the TODO notes: I wish we had some lightweight list of things that we as
maintainers agree that is easy to do, we have a clear NFC or semantic change in
mind but nobody has the time doing it. I have in mind a lot of NFC refactors,
API cleanups where I never get to, but I wish would be done.
https://github.com/llvm/llvm-project/pull/112209
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
