Reported in https://github.com/github/codeql/issues/2650
I found this during a bit of spring cleaning in my working
directory. As this doesn't have any immediate security implications, I
don't know when we'll get round to fixing it, but it can't hurt to
have the test case checked in.
In general, if there is _some_ decorator on a function, it might not be safe to
track content out of it (since the decorator could do anything), but in this
case, we can see what the decorator does, so we should be able to handle it (but
we don't right now).
By my understanding of how type-tracking works, if we track content through
`my_decorator`, then we would also track content to the result of
`unrelated_func()`, which I wanted to make sure our tests would catch.
I found out the core of the problem seems to come from our lack of being able to
track to the inner scope, and added an explicit test for that.
At this point, we may want to reconsider whether we really want the
deeply-nested module structure we had before (and which made the type
trackers somewhat bearable).
There's also a question of how we can make this a bit more
smooth. I think we need to consider exactly how we would like the
interface to this to work.
This is not strictly necessary, but it was bothering me that this
simply covered _all_ nodes that were both definitions and names at the
same time. Now it actually encompasses what the documentation claims
it does.
This is slightly dubious, and should really be in the currently
unimplemented "def" counterpart to the "use" bits we already have.
However, it seems to work correctly, and in the spirit of moving
things along, this seemed like the easier solution. We can always
replace the implementation with the "proper" approach at a later point.
Most of the type trackers in this model were easily replaceable with
uses of the API graph, but the ones for tracking subclasses are
problematic, as these take us out of the API graph.
In lieu of removing the offending flow (which would likely have
consequences for a lot of other tests), I opted to simply _include_
the relevant nodes directly.
There is now a bit of redundancy in the tests, but I thought it useful
to actually include some of the cases called out explicitly in the
documentation, so as to make it easy to see that the code actually
does what we expect (in these cases, anyway).
