summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenModule.cpp
diff options
context:
space:
mode:
authorArtem Dergachev <artem.dergachev@gmail.com>2018-09-25 22:10:12 +0000
committerArtem Dergachev <artem.dergachev@gmail.com>2018-09-25 22:10:12 +0000
commit579cf903673c9626e727ef90a6b7d2143f460b0e (patch)
tree54400d79dd3ed2fe650143d93902dbf1b118d369 /clang/lib/CodeGen/CodeGenModule.cpp
parent4e62418b25de4dcf476c54e77e48abd39821332b (diff)
downloadbcm5719-llvm-579cf903673c9626e727ef90a6b7d2143f460b0e.tar.gz
bcm5719-llvm-579cf903673c9626e727ef90a6b7d2143f460b0e.zip
[analyzer] NFC: Legalize state manager factory injection.
When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying. So far two checkers wanted a multimap, and both decided to trick the ProgramStateManager into keeping the auxiliary factory within itself by pretending that it's some sort of trait they're interested in, but then never using this trait but only using the factory. Make this trick legal. Define a convenient macro. One thing that becomes apparent once all pieces are put together is that these two checkers are in fact using the same factory, because the type that identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>, is the same. This situation is different from two checkers registering similar primitive traits. Differential Revision: https://reviews.llvm.org/D51388 llvm-svn: 343035
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud