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.
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).
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).
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.
In hindsight, having a `.getMetrics()` method that just returns `this`
is somewhat weird. It's possible that it predates the existence of the
inline cast, however.
Our previous modelling did not account for the fact that a lookahead can
potentially extend all the way to the end of the input (and similarly,
that a lookbehind can extend all the way to the beginning).
To fix this, I extended `firstPart` and `lastPart` to handle lookbehinds
and lookaheads correctly, and added some test cases (all of which yield
no new results).
Fixes#20429.
