Moved RangedConstraintManager header from lib/StaticAnalyzer/Core/ to clang/StaticAnalyzer/Core/PathSensitive/. No changes to the code.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
In the previous implementation, the Z3 wrapper classes were not inside the clang::ento namespace, and this patch doesn't change that.
Should it be part of the clang::ento namespace?
Let's change the return type and add namespace (in my understanding it was previously not required as the class was not exposed).
Otherwise, looks good to me.
@ddcc any objections?
lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp | ||
---|---|---|
1408 ↗ | (On Diff #149502) | should we return a unique_ptr over Z3ConstraintManager now? |
- Added Z3 wrapper classes to the clang::ento namespace
- Remove unnecessary headers from Z3ConstraintManager.h/.cpp
almost there, should we change the return type of CreateZ3ConstraintManager?
include/clang/StaticAnalyzer/Core/PathSensitive/Z3ConstraintManager.h | ||
---|---|---|
15 ↗ | (On Diff #149510) | @ddcc BTW why are we using this header? It's comments explicitly state it should not be used by the application. |
lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp | ||
1406 ↗ | (On Diff #149510) | this is still returning a constraint manager |
include/clang/StaticAnalyzer/Core/PathSensitive/Z3ConstraintManager.h | ||
---|---|---|
15 ↗ | (On Diff #149510) | This is generated by cmake and we need it because it defines CLANG_ANALYZER_WITH_Z3, when CLANG_ANALYZER_BUILD_Z3=ON |
lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp | ||
1408 ↗ | (On Diff #149502) | CreateZ3ConstraintManager follows the same pattern of CreateRangeConstraintManager, defined in ConstraintManager.h. They both return an unique_ptr<ConstraintManager> because neither Z3ConstraintManager nor RangeConstraintManager are defined in that header and the macro ANALYSIS_CONSTRAINTS in StaticAnalyzer/Core/Analyses.def expects a std::unique_ptr<clang::ento::ConstraintManager> (*)(clang::ento::ProgramStateManager&, clang::ento::SubEngine*). |
It was not a problem before because the implementation was only in the cpp file. Any idea how we can make use of it now?
They both return an unique_ptr<ConstraintManager> because neither Z3ConstraintManager nor RangeConstraintManager are defined in that header
I think we could do something here either with forward declaration or with other tricks.
In any case, let's just commit this as is, and later I'll see whether we could get rid of the cast.
include/clang/StaticAnalyzer/Core/PathSensitive/Z3ConstraintManager.h | ||
---|---|---|
15 ↗ | (On Diff #149510) | @mikhail.ramalho right, thanks, that sounds correct! |
The config.h in the Z3ConstraintManager.h is a problem, we can't merge it like that.
The problem is when you do make install, the config.h header is not installed (because it's only relevant during compilation). So anyone using Z3ConstraintManager.h will get a compilation error due to the missing config.h header.
@mikhail.ramalho OK could we instead make sure that cmake would propagate the macro to the required translation unit?..
E.g. by adding -DCLANG_ANALYZER_WITH_Z3 to CFLAGS.
@mikhail.ramalho after giving it some more thought...
I think we should remove "#include<z3.h>" from Z3ConstraintManager.h. That might require fiddling with private functions, the easiest way would be to turn them into C static functions and move to the .cpp file. Then only the implementation file would require Z3 internals, and the header could be always included.
@mikhail.ramalho It might be even better to create a generic SMT-solver header (a subset of current Z3ConstraintManager.h).
Then we could use that instead, and move Z3ConstraintManager back to the implementation file.
It's actually a feature that the included header should not expose Z3 internals.
I agree, creating a generic SMT-solver header seems the best way forward in
the long run.
I'll start to work on it now.
I agree, creating a generic SMT-solver header seems the best way forward in the long run.
Right, but let's remember that we are under rather severe time pressure.
I strongly suggest to just take only the bare minimum of methods you need now (we just need to get a model and add range constraints, right?)
Others could be added later.
The refactoring is fine with me.
I agree that exposing the Z3* internal wrapper classes seems a bit excessive.
If you plan to do a generic SMT-solver header, I'd suggest also pulling out the type inference and conversion code, since it should be in front of any SMT solver backend. But given the complexity, I'm fine with short-term fixes.
Split this patch in two, this one will only contain the RangedConstraintManager header change.