Internal Compilation Framework - Optimizing multiple compilation groups

[alexroan]

Currently, WorkspaceContext objects are built for each compilation group. For each detector, each WorkspaceContext must be passed in. This is not efficient.

Idea 1: WorkspaceContext handles multiple compilation groups 🤔 ❔

Question: Why can't WorkspaceContext handle all the compilation groups, whereby each HashMap looks something like this:

    // Double HashMap, or a BTreeMap? Or whatever is the most efficient to alter and access?
    pub(crate) assignments_context: HashMap<CompilationGroup, HashMap<Assignment, NodeContext>>,

Answer: Because getters must return both the compilation group and the actual node to avoid NodeID conflicts when browsing the context. This breaks the existing detectors, as they must handle the multiple WorkspaceContext objects. This is, therefore, not an option.

UPDATE: This could actually work if we altered all references of NodeID in the WorkspaceContext to ASTNode!

Idea 2: Implant compilation group into each ASTNode object 🤔 ❔

Question: Can we:

1. Add a new item to every Node type called compilation_group. This can be an integer.
2. After the compilation groups are obtained, inject the compilation_group value into the traversal of the AST via the accept function.
3. WorkspaceContext HashMaps can stay the same. The only one that would need to change is the pub nodes: HashMap<NodeID, ASTNode>,, which changes to include the compilation_group in the lookup. This prevents clashes when browsing the tree.
4. Browser functionality should account for the extra context within each node, compilation_group as well as NodID (Although, this may already be covered by the nodes change in point 3.

This means that we only need 1 WorkspaceContext so detectors are only run once. We still do a single traversal of the tree. We don't get clashes between compilation groups.

Answer: I think so! What do you think @TilakMaddy ?

[TilakMaddy]

Thanks for opening up this discussion : )

It'll take me some time to go through them ... but I would like to lay out my current picture of how I see the whole thing. Later I'll give my thoughts on both the ideas

So first let's break down the optimization pipeline of Aderyn into 3 phases.

Phase 1: Generation of the ASTs (to be implemented - parallelly run solc commands for all the contexts in ICF)
Phase 2: Deserializing them in Rust data structures (Idea 1 or Idea 2)
Phase 3: Detectors' code (Self explanatory)

[TilakMaddy]

Question - Say I have 3 contexts and each context has 20 assignments.

Now if my goal is to capture all the assignments what do I gain by looping through a single context containing 60 assignments that I don't get by looping through 3 contexts with 20 assignments each ?

[alexroan]

When you put it like that, I agree. Maybe this is less important than previously thought.