I could also move RangedConstraintManager.h under include/ if you agree as it seems slightly out of place under lib/.
Details
- Reviewers
NoQ george.karpenkov dcoughlin rnkovacs - Commits
- rG6c4c55ce9e67: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
rL333179: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
rC333179: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
Diff Detail
- Repository
- rC Clang
Event Timeline
I could also move RangedConstraintManager.h under include
We probably don't want to do that: currently it can only be imported by files in Core, and we probably should keep it that way
lib/StaticAnalyzer/Core/RangedConstraintManager.h | ||
---|---|---|
130 | Why not also REGISTER_TRAIT_WITH_PROGRAMSTATE here? |
Another approach would be to instead teach RangedConstraintManager to convert it's constraints to Z3. That would be an unwanted dependency, but the change would be much smaller, and the internals of the solver would not have to be exposed. @NoQ thoughts?
lib/StaticAnalyzer/Core/RangedConstraintManager.h | ||
---|---|---|
130 | 33 /// The macro should not be used inside namespaces, or for traits that must 34 /// be accessible from more than one translation unit. 35 #define REGISTER_TRAIT_WITH_PROGRAMSTATE(Name, Type) \ 36 ... I don't remember why. |
Dunno. Obviously, the adaptor code between the constraint manager and the refutation manager (i think the word "solver" is causing confusion now) would have to access internals of both managers, so the situation is quite symmetric.
I believe that many of our warning messages could be improved by presenting ranges to the user. Eg., ArrayBoundChecker could benefit from something like "index is within range [11, 12] and array size is equal to 10", and then a visitor that explains all the places in which the index was constrained to a smaller range. So in long term i'll be in favor of providing a way of explaining constraints to the users, which means partially exposing constraint manager internals to the checkers in a certain way (not necessarily *this* way). So for now i have no opinion on this issue :)
Why not also REGISTER_TRAIT_WITH_PROGRAMSTATE here?