Open rnk opened 1 year ago
@llvm/issue-subscribers-good-first-issue
Why does -Wdynamic-class-memaccess
even do a reachability analysis? This seems like a regular type-based warning, for which we typically don't check reachability. But there are lots of users of DiagRuntimeBehavior
/DiagIfReachable
, and potentially all of them are affected by this.
Always construct a CFG for analysis even in the presence of errors
Might be difficult. Especially if the error is in the same function, or affects the function in some way.
Don't issue any diagnostics about possibly unreachable code in the presence of other errors
That seems like the right approach to me. We do the same for -Wthread-safety-analysis
, and probably other CFG-based warning.
@rnk @aaronpuchert is this still open to work?
@rnk @aaronpuchert is this still open to work?
Yes, it seems.
@rnk @aaronpuchert Hello, is this issue open to work? It's my first time contributing to llvm!
I'm not aware of anyone working on this.
Consider: https://gcc.godbolt.org/z/dq6q8xxhY
This produces this
-Wdynamic-class-memaccess
warning:This goes away if you remove the
#error
.This causes issues because this latent warning can be present in header files in a warning-clean codebase, and it only appears when developers later introduce an error. The extra warning can obscure the actual problem because, with
-Werror
, developers end up seeing two errors.These two conditionals prevent Clang from doing CFG-based warnings in the presence of errors:
To fix the bug, we need to modify those conditionals to either:
I've prototyped both changes, and they break a lot of Clang tests, and I'm filing this issue to track followup.