Refactor of AE before adding Sparse Features

[bjjwwang]

Summary of Changes

Phase 1: Created IAbstractState.h interface

• File: SVF/svf/include/AE/Core/IAbstractState.h
• Created new abstract interface with pure virtual methods
  for state operations

Phase 2: Modified AbstractState to implement interface

• Files: AbstractState.h, AbstractState.cpp
• Added override specifiers to all interface methods
• Added clone() and getStateName() methods
• Changed widening/narrowing to return
  std::unique_ptr
• Added wideningDense/narrowingDense for internal
  backward-compatible usage
• Updated joinWith/meetWith to accept IAbstractState&
• Fixed missing include guards in AbstractValue.h

Phase 3: Decoupled AEDetector classes

• Files: AEDetector.h, AEDetector.cpp
• Changed all AbstractState& parameters to IAbstractState&
• Added override specifiers to virtual methods
• Added dynamic_cast to dense state where needed for
  AbsExtAPI compatibility

Phase 4: Decoupled AbstractInterpretation engine

• Files: AbstractInterpretation.h,
  AbstractInterpretation.cpp
• getAbsStateFromTrace() now returns IAbstractState&
• Added getDenseAbsStateFromTrace() for internal use
• Added createState() factory method (placeholder for
  sparse state)
• Updated internal usages to use dense accessors

Phase 5: Added use-sparse CLI options (TODO)

• Files: Options.h, Options.cpp
• Added -use-sparse CLI option (defaults to false)
• Factory method will assert if sparse state is requested
  (not yet implemented)

[yuleisui]

Phase 1:
If the AbstractState interface will be used extensively, including in other repositories, it would be better to keep the name AbstractState for the interface and rename the current AbstractState to AbstractStateImpl.

Phase 2:
Why do we need std::unique_ptr wrapping for widening and narrowing?
Do we still need backward compatibility for wideningDense and narrowingDense? We should aim to simplify the current implementations as much as possible for AE.

Phases 3 and 4:
Could we try to simplify the code by removing parts that are no longer used or are unnecessarily complex?

[bjjwwang]

Phase 1: If the AbstractState interface will be used extensively, including in other repositories, it would be better to keep the name AbstractState for the interface and rename the current AbstractState to AbstractStateImpl.

Phase 2: Why do we need std::unique_ptr wrapping for widening and narrowing? Do we still need backward compatibility for wideningDense and narrowingDense? We should aim to simplify the current implementations as much as possible for AE.

Phases 3 and 4: Could we try to simplify the code by removing parts that are no longer used or are unnecessarily complex?

Sure, I'll check it.

[codecov]

Codecov Report

❌ Patch coverage is 87.93103% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.16%. Comparing base (25f4c58) to head (93755cf).
⚠️ Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
svf/lib/AE/Svfexe/AEDetector.cpp	87.23%	6 Missing ⚠️
svf/include/AE/Svfexe/AEDetector.h	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1785      +/-   ##
==========================================
+ Coverage   64.15%   64.16%   +0.01%     
==========================================
  Files         243      243              
  Lines       24569    24576       +7     
  Branches     4627     4630       +3     
==========================================
+ Hits        15762    15769       +7     
  Misses       8807     8807              

Files with missing lines	Coverage Δ
svf/include/AE/Svfexe/AbstractInterpretation.h	95.23% <ø> (ø)
svf/lib/AE/Svfexe/AbstractInterpretation.cpp	80.69% <100.00%> (+0.11%)	⬆️
svf/include/AE/Svfexe/AEDetector.h	97.91% <85.71%> (+0.04%)	⬆️
svf/lib/AE/Svfexe/AEDetector.cpp	85.77% <87.23%> (+0.12%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yuleisui]

It looks that we can't use AbstractState anymore? Every place has to be replaced with AbstractStateImpl?

If that is the case, we will have to use AbstractStateInterface and keep AbstractState as the implementation.

[yuleisui]

Do we still need this pull request? If not, please close it

[yuleisui]

Do we still need this pull request? If not, it can be closed. Please update the next stage regarding the baseline for the medium-large benchmarks.

[bjjwwang]

ok I close it.