Python: Port import-related queries away from points-to#21379
Draft
Python: Port import-related queries away from points-to#21379
Conversation
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.
Uses a (perhaps) slightly coarser approximation of what modules are imported, but it's probably fine.
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.
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.
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.
Only trivial test changes.
Depending on whether other queries depend on this, we may end up moving the exception utility functions to a more central location.
Approximates the behaviour of `Types::isNewStyle` but without depending on points-to
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).
Only trivial test changes.
Only trivial test changes.
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.
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).
No test changes.
Only trivial test changes.
Included test changes are trivial `toString` changes.
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).
Adds `overridesMethod` and `isPropertyAccessor`.
Only trivial test changes.
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.
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).
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).
Only trivial test changes.
No test changes.
Adds support for finding instances, and adds a `BaseException` convenience class.
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.
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.
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.
Adds `if False: ...` and `if typing.TYPE_CHECKING: ...` to the set of nodes that are unlikely to be reachable.
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.
A fairly straightforward port. No test changes.
No test changes.
Changes the "has points-to value" check into a "is reachable" check instead. No test changes.
f6b201c to
54bdf6f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WIP