PhASAR's API for implementing IDE analyses requires implementing EdgeFunctions. However, when implementing such an ananlysis, we tend to implement the same few edge functions over and over again as there are insufficient defaults. Additionally, the deep integration with std::shared_ptr is unintuitive and error-prone. Finally, we use llvm::dyn_cast for runtime type-checking everywhere in PhASAR, only for EdgeFunctions we use dynamic_cast instead. This is unintuitive as well and difficult to teach.
Improve this.
Prerequisites
issue x
Out Of Scope
A isn't part of this
Acceptance Criteria
The following acceptance criteria are defined regarding the result of this story:
Clarify what the final result should be, not how to accomplish it.
[x] Commonly used EdgeFunctions are provided by PhASAR with a proper default implementation, such that client analyses can focus on what matters
[x] Clients do not have to explicitly deal with std::shared_ptr for EdgeFunctions anymore, no matter what memory representation is then used in the underlying implemenation details
[x] Dynamic casting on edge functions should work with LLVM's casting primitives (llvm/Support/Casting.h)
Story
PhASAR's API for implementing IDE analyses requires implementing EdgeFunctions. However, when implementing such an ananlysis, we tend to implement the same few edge functions over and over again as there are insufficient defaults. Additionally, the deep integration with std::shared_ptr is unintuitive and error-prone. Finally, we use llvm::dyn_cast for runtime type-checking everywhere in PhASAR, only for EdgeFunctions we use dynamic_cast instead. This is unintuitive as well and difficult to teach.
Improve this.
Prerequisites
Out Of Scope
Acceptance Criteria
The following acceptance criteria are defined regarding the result of this story: Clarify what the final result should be, not how to accomplish it.
Related Stories
Follow-up Stories