================
@@ -338,8 +338,9 @@ auto isValueOrNotEqX() {
}
auto isZeroParamConstMemberCall() {
- return cxxMemberCallExpr(
- callee(cxxMethodDecl(parameterCountIs(0), isConst())));
+ return cxxMemberCallExpr(callee(cxxMethodDecl(
+ parameterCountIs(0), isConst(),
+ unless(hasAnyName("value", "has_value", "hasValue", "operator bool")))));
----------------
zeyi2 wrote:
Sorry for the late reply:
> Didn’t we discuss that this solution might be more of a hack, and that the
> root cause could be different?
Yes, exactly. This is the main reason I've kept this PR as a Draft.
I am currently re-verifying my initial analysis to ensure no details were
missed. If the root cause is indeed the conservative nature of the dataflow
analysis (as I suspect), fixing it would be challenging. Making the analysis
less conservative could introduce new issues or false negatives, which IMHO
might be risky...
> 1. Should we extend the list with more method names, e.g. `isNull` from
> `BloombergLP::bdlb::NullableValue`?
> 2. Can we add a test to double-check that by ignoring methods...
Sure. I'll add them :)
Regarding the current status of this PR:
- The first commit breaks existing tests...
- After fixing the CI failure, the FP comes back in real-world scenarios but
disappears in unit tests using simplified mock std implementations.
So there are some differences between the mock std and the actual
implementation that trigger this discrepancy (AFAIK the FP is caused by a
variable inside std implementation). I'm still trying to create a reliable
reproduction case that mirrors the real-world.
I will update the PR once I have a more concrete path forward.
https://github.com/llvm/llvm-project/pull/177858
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
