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.
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).
A slightly odd fix, but still morally okay, I think. The main issue
here was that global variables have their first occurrence in an inner
scope inside a so-called "scope entry definition", that then
subsequently flows to the first use of this variable. This meant that
that first use was _not_ a `LocalSourceNode` (since _something_ flowed
into it), and this blocked `trackUseNode` from type-tracking to it (as
it expects all nodes to be `LocalSourceNode`s).
The answer, then, is to say that a `LocalSourceNode` is simply one
that doesn't have flow to it from _any `CfgNode`_ (through one or more
steps). This disregards the flow from the scope entry definition, as
that is flow from an `EssaNode`.
Additionally, it makes sense to exclude `ModuleVariableNode`s. These
should never be considered local sources, since they always have flow
from (at least) the place where the corresponding global variable is
introduced.
This turned out to be fairly simple. Given an import such as
```python
from foo.bar.baz import quux
```
we create an API-graph node for each valid dotted prefix of
`foo.bar.baz`, i.e. `foo`, `foo.bar`, and `foo.bar.baz`. For these, we
then insert nodes in the API graph, such that `foo` steps to `foo.bar`
along an edge labeled `bar`, etc.
Finally, we only allow undotted names to hang off of the API-graph
root. Thus, `foo` will have a `moduleImport` edge off of the root, and
a `getMember` edge for `bar` (which in turn has a `getMember` edge for
`baz`).
Relative imports are explicitly ignored.
Finally, this commit also adds inline tests for a variety of ways of
importing modules, including a copy of the "import-helper" tests (with
a few modifications to allow a single annotation per line, as these
get rather long quickly!).
