Conversation
It is a little funky. I think it is designed exactly to get the "next-to-immediate" uses, since the immediate uses are imports and we want "the first uses inside the request handlers". It is causing some problems, as discussed here (and further in the linked, internal issue). The upshot is, I think, that it often cuts out the immediate use and therefor you had to revert in order to preserve results. |
yoff
left a comment
yoff
left a comment
There was a problem hiding this comment.
This is great! So many simplifications, and the new code often concisely shows the intent :-D
2 participants
I took another look at your code after our recent API-graph talks.
I've refactored a bunch, but you still have a whole lot of type-trackers left.
I don't think the remaining uses of type-trackers can be refactored to API-graphs.
A lot of the remaining type-trackers start tracking from an abstract-class that are not guaranteed to be an API-node.
And a bunch of them rely of edges not currently included in API-graphs (subscript, ...).
You had a lot of type-trackers that started with
node::getAUse(), and then tracked from there.It's redundant to use
getAUse()and then afterwards type-track the results, so I converted those togetAnImmediateUse().I also looked through all uses of
getAUse()and refactored anything that looked suspicious.I'm a bit puzzled by that last revert I had to do.
It's an remote flow source, and thus some global dataflow library or something to track from the origin, thus rendering any type-tracking redundant.
But there are a bunch of checks in there that only makes sense for local uses (and not the immediate use), and I loose many results by using
getAnImmediateUse().It looks suspicious, but I don't understand what's happening enough to do anything about it.