If an error happens which is related to a container the Container Modeling checker adds note tags to all the container operations along the bug path. This may be disturbing if there are other containers beside the one which is affected by the bug. This patch restricts the note tags to only the affected container and adjust the debug checkers to be able to test this change.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I believe our path and context sensitive engine is more extensible and precise than checking the source file. Are you sure it scales? I would prefer to tie this information for MemRegions, rather than arbitrary places in the source code. My knowledge is very weak in this checker but I have changed from the Tidy world to the Analyzer to enjoy its benefits. Please enjoy these benefits in your work as well.
Alternative approach for debugging (instead of checking the source range): clang_analyzer_express() from ExprInspection marks its argument as interesting in the bug report. DebugContainerModeling propagates the interestingness from the symbol (begin or end symbol of the container) to the container itself.
Cool, that one a lucky one! I think the SymbolRef based world also working, just at some point it could not scale because other systems are region based... For now, it is a much better solution, and this pattern to overload the callback with all the interestingness seems like the standard way of using NoteTags. Thanks!
I don't have any technical comments on this patch since I haven't used NoteTags yet, only a couple of readability ones.
clang/lib/StaticAnalyzer/Checkers/DebugContainerModeling.cpp | ||
---|---|---|
97–103 | Probably a flattened version would be more readable. auto *PSBR = dyn_cast<PathSensitiveBugReport>(&BR); if (PSBR && PSBR->isInteresting(Field)) PSBR->markInteresting(Cont); return ""; | |
clang/test/Analysis/container-modeling.cpp | ||
218 | I'm not sure about the convention about using dashes, but I've seen multiple time comments like this: | |
232–234 | This line looks quite crowded, can't we use expected-note@-1 here just like it was used previously? |
Because UndefinedVal seems to be the "null" value of SVal thus it is suitable for default value of the parameter.
Shouldn't we use Optional then? None means something completely different then UndefinedVal.
clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp | ||
---|---|---|
55–61 | I would also prefer to comment what happens when ExprVal has a special value, because its non-obvious from the declaration. |
It is not. It is a very specific and exotic SVal that almost never appears in practice but plays a very important role in the analysis.
Let's remove the default constructor for SVal entirely because it seems to be a common source of confusion.
clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp | ||
---|---|---|
723–724 | Mmm, this is definitely impossible. We should change the NoteTag API to pass in a PathSensitiveBugReport &. My bad. |
clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp | ||
---|---|---|
723–724 | Good idea. For now I changed it to simple cast<>() without check. |
It is. The one accepted earlier will be committed earlier, then I will rebase the other one so this part disappears from that one.
clang/test/Analysis/container-modeling.cpp | ||
---|---|---|
99–100 | We did not unpack this but forgot to pack it. |
clang/lib/StaticAnalyzer/Checkers/DebugContainerModeling.cpp | ||
---|---|---|
32 | Is that a thing? Nice. |
clang/lib/StaticAnalyzer/Checkers/DebugContainerModeling.cpp | ||
---|---|---|
32 | You mean a callback instead of a template? |
clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp | ||
---|---|---|
726 | Theoretically yes, because llvm::StringRef has a conversion operator for std::string. However, when compiling I get a compilation error: error: could not convert `Out.llvm::raw_svector_ostream::str()` from `llvm::StringRef` to `std::__cxx11::string {aka std::__cxx11::basic_string<char>}` |
Mmm, this is definitely impossible. We should change the NoteTag API to pass in a PathSensitiveBugReport &. My bad.