One of the tests fails at the moment because the specification node has two entries associated with it in the flowgraph. One is the scope-in and one is the scope-out. I think the analysis is currently picking the scope-out node and looking beyond that, where -- surprise, surprise -- the variable is not used again. So I need some easy way of telling the flow analyses which of the two nodes I want to start from, in this case and other ones where I also add two nodes related to the same point in the AST.
It used to just be the list of target type keys. It's now a map from
all possible type keys to a precomputed hit/through/miss decision for
them. gmapMFor can therefore dig into "through" types without needing
to (fail to) apply the generic function first.
This makes less difference than I was expecting: it shaves the time
for cgtest24 from 2m30 down to 2m15.
This provides gmapMFor and gmapMFor2, which are like gmapM, but know what
they're looking for, and can therefore avoid going down branches of the tree
that won't contain any interesting types.
The basic approach is quite similar to Uniplate's PlateData: there's a function
(containsType) that'll tell you whether one type is contained somewhere within
another. However, unlike Uniplate, we build a static IntMap IntSet of the types
we need to know about, which allows rather quicker lookups. (I did try using
PlateData first.)
The result is that applyDepthM is now much quicker than it was before.
applyDepthM2 is a bit less impressive, which I assume is because it can't
really prune the tree much if it's looking for two types.
Future enhancements:
- convert more passes to use applyDepthM*;
- make gmapMFor* aware of constructors rather than just types, which should
allow a bit more pruning.
