there should be a finer set of tests for the pure algorithm, in simple-graph's test code.
Algorithm (!) the algorithm can avoid storing so much in the caches -- by creating a list of lists of all paths as another run after all edges have been marked with their final "leads to target" status. It should reduce memory consumption at the cost of another pass (O(E)) on the graph, or on a subset of it that only contains nodes/edges that are "leads to target" = true.
Consider the list creating approach e.g. described here and demonstrated here as an alternative for avoiding excessive storage at each node/vertex, or for a way to create the list of paths - however note a list including edges is needed in our domain here as we look at the edges types not just sterile edges.
Algorithm (!) the algorithm should memoize (cache status for) edges not vertices
there should be more graph-laden negative testing, in the compiler plugin's unit tests, in addition to the "positive" ones, for the simple cases. Then there can be added more tests as part of related tasks exploring correct capture from code examples.
Also explore tail recursion to justify the recursive implementation...
The algorithm for finding acceptable paths between two nodes and its usage in the compiler plugin's unit test code need to be stepped up into better shape:
O(E)) on the graph, or on a subset of it that only contains nodes/edges that are "leads to target" = true. Consider the list creating approach e.g. described here and demonstrated here as an alternative for avoiding excessive storage at each node/vertex, or for a way to create the list of paths - however note a list including edges is needed in our domain here as we look at the edges types not just sterile edges.Also explore tail recursion to justify the recursive implementation...