The new CyclicImports.qll is a fairly straight port of Cyclic.qll, with
the main changes being:
- We now use Module instead of ModuleValue everywhere
- We use getModuleReference instead of pointsTo
- is_import_time was replaced with a use of `ImportTimeScope`
The predicate that changed the most is `stmt_imports`, which in the
original just did `s.getASubExpression().pointsTo(result)`. The new
version has three branches, one for each kind of import, and with
special handling of imports from within a submodule (which is not
something that should be flagged).
No test changes.
Uses the existing machinery in ImportResolution.qll, after adding a few
convenience predicates.
The new modelling actually manages to find a result that the old
points-to analysis did not. Apart from that there are no test changes.
A few relevant changes compared to the points-to version:
- we've lost `origin`, so we can no longer point to where the illegal
type lives. I opted to keep the output message the same, mirroring what
we were already doing in IllegalRaise.ql.
- We no longer track literal values flowing in from elsewhere, so we
lost a single test result where the handled "type" is the result of
calling a float-returning function.
Apart from that, the only test changes are cosmetic.
Adds a convenient way to get the class name for an immutable literal (to
maintain the same output format as was provided by the points-to
version). I don't know if people are in the habit of writing `raise 5`,
but I guess `raise "NotImplemented"` (wrong on so many levels) is not
entirely impossible.
No test changes.
Note that this does not give the exact same results as the old function,
however it's not clear to me that the old results were actually correct
(it _looks_ like `read()` might be doing an IO operation, but in fact
`read` is not defined, so at best this will raise a NameError, not an
IOError).
The implementation is essentially the same as the one from
`BasicBlockWithPointsTo`, with the main difference being that this one
uses the exception machinery we just added (and some extensions added in
this commit).
This analysis will is needed for the reachability modelling (which
tracks things like which exceptions are caught by which handles), so it
makes more sense for it to move to `DataFlowDispatch` for now.
These results are missing because we no longer (unlike the points-to
analysis) track how many elements a given tuple has. This is something
we might want to implement in the future (most likely through an
`int`-indexed type tracker).
This one is a bit more involved. Of note is the fact that it at present
only uses local flow when determining the origin of some value (whereas
the points-to version used global flow). It may be desirable to rewrite
this query to use global data-flow, but this should be done with some
care (as using "all unhashable objects" as the set of sources is
somewhat iffy with respect to performance). For that reason, I'm
sticking to mostly local flow (except for well behaved things like types
and built-ins).
For this one we actually lose a test result. However, this is kind of to
be expected since we no longer have the "precise" MRO that the points-to
analysis computes.
Honestly, I'm on the fence about even keeping this query at all. It
seems like it might be superfluous in a world with good Python type
checking.
These could arguably be moved to `Class` itself, but for now I'm
choosing to limit the changes to the `DuckTyping` module (until we
decide on a proper API).
Same comment as for the preceding commit. We lose one test result due to
the fact that we don't know what to do about `for ... in 1` (because `1`
is an instance of a built-in). I'm going to defer addressing this until
we get some modelling of built-in types.
Uses the new `DuckTyping` module to handle recognising whether a class
is a container or not. Only trivial test changes (one version uses
"class", the other "Class").
Note that the ported query has no understanding of built-in classes. At
some point we'll likely want to replace `hasUnresolvedBase` (which will
hold for any class that extends a built-in) with something that's aware
of the built-in classes.
This module (which for convenience currently resides inside
`DataFlowDispatch`, but this may change later) contains convenience
predicates for bridging the gap between the data-flow layer and the old
points-to analysis.
Removes the use of points-to for accessing various built-ins from three
of the queries. In order for this to work I had to extend the lists of
known built-ins slightly.
Adds `hasOverloadDecorator` as a predicate on functions. It looks for
decorators called `overload` or `something.overload` (usually
`typing.overload` or `t.overload`). These are then filtered out in the
predicates that (approximate) resolving methods according to the MRO.
As the test introduced in the previous commit shows, this removes the
spurious resolutions we had before.
