Remove constraint that an initializing expression of struct type must have an
associated Value. This invariant is not and will not be guaranteed by the
framework, because of potentially uninitialized fields.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
184–186 | The patch makes sense to me in the current state, but it's unclear why is this not something that we'd like to do in the long term. |
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
184–186 | Because of uninterpreted fields. If we consider those a temporary fix, then I agree about the long term. I'd thought those were here to stay. That said, if we find a way to either interperet fields lazily or only interpret those needed in the current function scope, we may be able to avoid uninterpreted expressions. This also begs the question as to why we insist on initializing the variable. Arguably, if the expresssion is uninterpreted, so should be the variable. So, we should at least explain why we're distinguishing. Thoughts on my adding a comment to that effect? |
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
184–186 |
Could you elaborate on this? Do you mean fields being uninterpreted due to hitting a depth limit or being recursive? Or is this something else? |
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
184–186 | Not initializing the variable in such cases also makes sense to me. I'd very much appreciate a comment. I suggest also keeping the FIXME as interpreting fields lazily (and thus relying that all fields that are accessed are initialized) is still an option. |
The patch makes sense to me in the current state, but it's unclear why is this not something that we'd like to do in the long term.