- Existing IFDS/IDE problems provided by PhASAR do no longer inherit from
IFDSTabulationProblem/IDETabulationProblem. The solvers can now deal with them without polymorphic inheritance hierarchy. However, you cannot cast an analysis problem to one of these base classes anymore. If that's required (unlikely), wrap your problem in aLegacyIDEProblemWrapper.- Although the IFDS/IDETabulationProblem classes still work, new IFDS/IDE analysis problems should conform to the
IFDSProblem/IDEProblemconcepts instead. UseIfdsIdeProblemMixinas helper for that.
- Although the IFDS/IDETabulationProblem classes still work, new IFDS/IDE analysis problems should conform to the
IDESolverandIFDSSolvernow take analysis problems by pointer instead of by reference to better document that they capture the address (without taking ownership).FlowFunctionPtrTypeis now a move-only type.- Removed the CRTP-template
ProjectIRDBBase. Use the conceptProjectIRDBinstead. - Removed
EdgeFunction<L>::equals. Useoperator==instead. - Removed ctor-overloads of
LLVMProjectIRDBthat use theEnableOpaquePointersparameter. LLVM is removing support for opaque pointers. Use the other ctors instead. - Removed type-trait
has_getAsJson, as it is not used in our codebase anymore. We switched fromgetAsJsontoprintAsJsona while ago.
-
The function
HelperAnalyses::getAliasInfo()no longer returns aLLVMAliasSet &, but aLLVMAliasInfoRef. -
The location of the library summary
FunctionDataFlowFactsandLLVMFunctionDataFlowFactshas moved tophasar/Utils/andphasar/PhasarLLVM/Utils, respectively. -
IDESolver::initialize()does no longer return abool. Now, you are always allowed to callnext()at least once. -
IntraMonoProblemandInterMonoProblem, and all reference-implementations of these problems do not receive a TypeHierarchy-pointer anymore in the ctor. -
Requiring C++20 instead of C++17
- Type-traits and other templates that are specialized now use
requiresinstead ofenable_if, wherever possible. This may reduce the number of (defaulted) template parameters in some cases.
- Type-traits and other templates that are specialized now use
-
The
AdjacencyListstruct now now has one more template argument to denote the intege-likevertex_ttype. It is the second template argument (which previously was the EdgeType). The edge-type is now denoted by the third template argument. -
The
AdjacencyListswitches from usingllvm::NoneTypeas empty-node marker topsr::EmptyTypefor forward-compatibility with LLVM-16 that removesllvm::NoneType. -
Removed
SpecialSummaries. -
Removed
Hexastoreand the corresponding database queries. -
Removed
LLVMTypeHierarchy(andLLVMTypeHierarchyData), which is superceeded byDIBasedTypeHierarchy. -
Removed
Resolver::preCall(),Resolver::postCall(), andResolver::otherInst(). -
Removed
TypestateDescription::start(). Instead applyTypestateDescription::getNextState()onTypestateDescription::uninit(). -
Removed
LLVMProjectIRDB::getParsedIRModuleOrNull(). UseLLVMProjectIRDB::getParsedIRModuleOrErr()instead. -
Removed
DIBasedTypeHierarchy::isVTable()andDIBasedTypeHierarchy::removeVTablePrefix(). Use the corresponding functions fromLLVMVFTableProviderinstead. -
Removed the CMake variable
PHASAR_HAS_SQLITEas we removed the dependency on sqlite3. -
The CMake Option
BUILD_PHASAR_CLANGis no longerONby default. -
Removed the dependency to boost:
- Removed the boost-related command-line options in
bootstrap.sh InstallAptDependencies.shno longer installs boost (so, boost is also no longer built into PhASAR's Docker containers)
- Removed the boost-related command-line options in
- Removed some old APIs from
PhasarConfig - Removed the header
phasar/Config/Version.h. Use the generated headerphasar/Config/phasar-config.hinstead. - Removed
getAsJson()from various classes. UseprintAsJson(llvm::raw_ostream &)instead. - Removed
CallGraphAnalysisType::DTAand theDTAResolver(see below) - Removed the legacy flow functions
Identity,LambdaFlow, etc. Use the static functions fromFlowFunctionTemplatesinstead. - Removed getter-functions from
GeneralStatistics. Use the corresponding public fields instead. - Removed
LLVMAliasGraph. UseLLVMAliasSetinstead. - Removed
TypeGraphs/*as they are not used. - Removed the namespace-scoped function
initializeLogger(). Use the static functions in theLoggerclass instead. - Removed
legacy::stripPointer(const llvm::Type *)as it does not work anymore with opaque pointers.
- The
DTAResolverand the cli option--call-graph-analysis=dtado not work anymore (due to opaque pointers) and will be removed for the next release. Please use theOTForRTAresolver instead. - The default type-hierarchy implementation has been changed from
LLVMTypeHierarchytoDIBasedTypeHierarchy. This also requires all affected analyses to be performed on LLVM IR that contains debug information. - Removed the phasar-library
phasar_controller. It is now part of the toolphasar-cli. - The API of the
TypeHierarchyinterface (and thus theLLVMTypeHierarchyandDIBasedTypeHierarchyas well) has changed:- No handling of the super-type relation (only sub-types)
- No VTable handling anymore -- has been out-sourced into
LLVMVFTableProvider - minor API changes
- The constructors of the call-graph resolvers have changed. They:
- take the
LLVMProjectIRDBas pointer-to-const - take an additional second parameter of type
const LLVMVFTableProvider * - not necessarily require a
LLVMTypeHierarchyanymore
- take the
- Some constructors of
LLVMBasedICFGdo not accept aLLVMTypeHierarchypointer anymore - Removed IfdsFieldSensTaintAnalysis as it relies on LLVM's deprecated typed-pointers.
- Versioning scheme has been changed from
<month><year>to<year><month> - Default build mode is no longer
SHAREDbutSTATIC. To build in shared mode, use the cmake optionBUILD_SHARED_LIBSwhich we don't recommend anymore. Consider usingPHASAR_BUILD_DYNLIBinstead to build one big libphasar.so. - Build type
DebugSanhas been removed in favor of a new CMake optionPHASAR_ENABLE_SANITIZERSthat not only works inDebugmode.
EdgeFunctionPtrTypeis no longer astd::shared_ptr. InsteadEdgeFunction<l_t>should be used directly.EdgeFunctionis now a value-type that encapsulates its memory management by itself.- Concrete
EdgeFunctiontypes no longer derive from any base-class. Instead they just need to implement the required API functions.EdgeFunctionimplementations should me move-constructible and can be implicitly cast toEdgeFunction. To verify that your type implements the edge function interface use theIsEdgeFunctiontype trait. The API functions have been changed as follows:- All API functions of
EdgeFunctionmust beconstqualified. EdgeFunctionPtrType composeWith(EdgeFunctionPtrType SecondFunction)andEdgeFunctionPtrType joinWith(EdgeFunctionPtrType OtherFunction)have been changed tostatic EdgeFunction<l_t> compose(EdgeFunctionRef<T> This, const EdgeFunction<l_t>& SecondFunction)andstatic EdgeFunction<l_t> join(EdgeFunctionRef<T> This, const EdgeFunction<l_t>& OtherFunction)respectively. Here, theThisparameter models the formershared_from_this().bool equal_to(EdgeFunctionPtrType Other)consthas been changed tobool operator==(const T &Other)const noexcept, whereTis your concrete edge function type.void print(llvm::raw_ostream &OS, bool IsForDebug)has been changed tofriend llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const T& EF).
- All API functions of
EdgeFunctionis tagged with[[clang::trivial_abi]]. Hence, you should not rely on any destruction order within a top-level statement that uses temporaryEdgeFunctionobjects.EdgeFunctionSingletonFactoryhas been removed. UseEdgeFunctionSingletonCacheinstead.TaintConfighas been renamed toLLVMTaintConfig. For generic code you may want to use the LLVM-independentTaintConfigBaseCRTP interface instead.- Renamed
phasar/PhasarLLVM/DataFlowSolver/to eitherphasar/DataFlow/orphasar/PhasarLLVM/DataFlow/depending on whether the components need LLVMCore. Analoguous changes inlib/andunittests/. An incomplete list of moved/renamed files:phasar/PhasarLLVM/DataFlowSolver/IfdsIde/Solver/*=>phasar/DataFlow/IfdsIde/Solver/*phasar/PhasarLLVM/DataFlowSolver/IfdsIde/IDETabulationProblem.h=>phasar/DataFlow/IfdsIde/IDETabulationProblem.hphasar/DB/LLVMProjectIRDB.h=>phasar/PhasarLLVM/DB/LLVMProjectIRDB.h- ...
- Renamed and split up some libraries:
phasar_phasarllvm_utils=>phasar_llvm_utilsphasar_typehierarchy=>phasar_llvm_typehierarchyphasar_ifdside=>phasar_llvm_ifdsidephasar_controlflowhas its LLVM dependent stuff moved tophasar_llvm_controlflowphasar_dbhas its LLVM dependent stuff moved tophasar_llvm_dbphasar_pointerhas its LLVM dependent stuff moved tophasar_llvm_pointer
- Renamed the phasar tool
phasar-llvmtophasar-cli LLVMPointsTo[.*]has been renamed toLLVMAlias[.*]- The ctor of
LLVMAliasSetnow takes theLLVMProjectIRDBas pointer instead of a reference to better document that it may capture the IRDB by reference. - The
PointsToInfointerface has been replaced by the CRTP interfaceAliasInfoBase. Introduced two type-erased implementations of that interface:AliasInfoandAliasInfoRef. In most cases you should replacePointsToInfo *andLLVMPointsToInfo *byAliasInfoRef, bzw.LLVMAliasInfoRef. - Introduced a new interface
PointsToInfoBaseand type-erased implementationsPointstoInfoandPointsToInfoRef. Don't confuse them with the oldPointsToInfo!!! (However, they have different APIs, so you should encounter compilation errors then)
- Removed virtual interfaces
CFG<N,F>andICFG<N,F>and replaced by CRTP interfacesCFGBaseandICFGBase. Use the concrete typesLLVMBasedICFGandLLVMBasedCFGinstead. In template code you can use the type traitsis_crtp_base_of_vandis_icfg_vto check for conformance to the interfaces. - The
LLVMBasedICFGnow takes the IRDB as pointer instead of a reference to better document that it may capture the IRDB by reference. - Renamed
ProjectIRDBtoLLVMProjectIRDBand added a generic CRTP interfaceProjectIRDBBasethat does not depend on LLVM - Changed the API of
LLVMProjectIRDB: The IRDB does no longer link multiple LLVM modules together, i.e. the ctor that reads a module from a file now takes a single filename instead of a vector. If you still want to link multiple LLVM modules together, use LLVM's Linker functionality instead.ProjecIRDB::getAllModules()has been removed andProjectIRDB::getWPAModule()has been renamed toLLVMProjectIRDB::getModule(). - The
LLVMProjectIRDBctor that takes a raw-pointer tollvm::Moduledoes no longer preprocess the module (i.e. attaching metadata IDs to it). You can still explicitly use theValueAnnotationPassto do so manually. - The type
WholeProgramAnalysishas been removed. UseAnalysisControllerinstead. - The IFDS and IDE TabulationProblems no longer take all of
LLVMProjectIRDB*,LLVMTypeHierarchy*,LLVMPointsToInfo*andLLVMBasedICFG*as an argument. Instead, they only get what they need. - The
IFDSSolverandIDESolvernow take an instance of theICFGBaseinterface as additional argument to their ctor (because the analysis problems now not necessarily store a reference to it anymore). - The
IDETabulationProblemis now a base class ofIFDSTabulationProblem(and not vice versa as it was previously). In their ctors they only take the bare minimum of arguments: The IRDB, the entrypoints and optionally the special zero-value. If the zero-value is not passed in the ctor (as it was previously), it has to be set from within the client analysis' ctor. You may use the new functioninitializeZeroValue(d_t)for this.