[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

This revision was automatically updated to reflect the committed changes. Closed by commit rL301224: [analyzer] Improve suppression for inlined defensive checks before operator &. (authored by dergachev). Changed prior to commit: https://reviews.llvm.org/D31982?vs=95890=96446#toc Repository:

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/Store.cpp:440 // well, although in reality we should return the offset added to that - // value. + // value. See also the similar FIXME in getLValueFieldOrIvar(). if (Base.isUnknownOrUndef() ||

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:977 + Ex = Op->getSubExpr()->IgnoreParenCasts(); + while (true) { +if (const auto *ME = dyn_cast(Ex)) { zaks.anna wrote: > Why do we need the

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:965 + +// Performing operator `&' on an lvalue expression is essentially a no-op. +// Then, if we are taking addresses of fields or elements, these are also zaks.anna

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ updated this revision to Diff 95890. NoQ marked 5 inline comments as done. NoQ added a comment. Fix comments! https://reviews.llvm.org/D31982 Files: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp lib/StaticAnalyzer/Core/Store.cpp test/Analysis/explain-svals.cpp

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

zaks.anna added a comment. Thanks!!! Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:965 + +// Performing operator `&' on an lvalue expression is essentially a no-op. +// Then, if we are taking addresses of fields or elements, these are also

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

dcoughlin accepted this revision. dcoughlin added a comment. This revision is now accepted and ready to land. Yay! This is going to fix some really confusing false positives.LGTM with Gabor's comments addressed. One note. I am not a big fan of using clang_analyzer_explain() in tests for

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

xazax.hun added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:975 + if (Op->getOpcode() == UO_AddrOf) +if (Op->getSubExpr()->isLValue()) { + Ex = Op->getSubExpr()->IgnoreParenCasts(); Maybe you could move this

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ updated this revision to Diff 95082. NoQ added a comment. Remove accidentally added braces in unrelated code. https://reviews.llvm.org/D31982 Files: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp lib/StaticAnalyzer/Core/Store.cpp test/Analysis/explain-svals.cpp

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:965 + +// Performing operator `&' on an lvalue expression is essentially a no-op. +// Then, if we are taking addresses of fields or elements, these are also alexshap

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

alexshap added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:965 + +// Performing operator `&' on an lvalue expression is essentially a no-op. +// Then, if we are taking addresses of fields or elements, these are also

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

NoQ created this revision. In code void foo(int *p) { if (p) {} } void bar(int *p) { foo(p); *p = 5; } we suppress the null dereference warning in `*p = 5` because the state split within the inlined function is essentially irrelevant, as this is merely a defensive check