I could also move RangedConstraintManager.h under include/ if you agree as it seems slightly out of place under lib/.
NoQ george.karpenkov dcoughlin rnkovacs
- rL333179: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
rC333179: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
rG6c4c55ce9e67: [analyzer] Move RangeSet related declarations into the RangedConstraintManager…
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
Why not also REGISTER_TRAIT_WITH_PROGRAMSTATE here?
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 :)