This frees `Class.qll`, `Exprs.qll`, and `Function.qll` from the
clutches of points-to. For the somewhat complicated setup with
`getLiteralObject` (an abstract method), I opted for a slightly ugly but
workable solution of just defining a predicate on `ImmutableLiteral`
that inlines each predicate body, special-cased to the specific instance
to which it applies.
For now, these have just been made into `private` imports. After doing
this, I went through all of the (now not compiling) files and added in
private imports to the modules that they actually depended on.
I also added an explicit import of `LegacyPointsTo` (even though it may
be unnecessary) in cases where the points-to dependency was somewhat
surprising (and one we want to get rid of). This was primarily inside
the various SSA layers.
For modules inside `semmle.python.{types, objects, pointsto}` I did not
bother, as these are fairly clearly related to points-to.
Moves the existing points-to predicates to the newly added class
`ControlFlowNodeWithPointsTo` which resides in the `LegacyPointsTo`
module.
(Existing code that uses these predicates should import this module, and
references to `ControlFlowNode` should be changed to
`ControlFlowNodeWithPointsTo`.)
Also updates all existing points-to based code to do just this.
for dbscheme elements with direct or indirect location links in dbscheme.
- Unify discardable entities under one Discardable superclass.
- Two discard predicates depending on TRAP ID type.
- Future-proof the XML and Yaml discard predicates for when their
extractors become incremental.
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.
Our current modelling only treated `psycopg2` insofar as it implemented
PEP 249 (which does not define any notion of connection pool), which
meant we were missing database connections that arose from such pools.
With these changes, we add support for the three classes relating to
database pools that are defined in `psycopg2`. (Note that
`getAnInstance` automatically looks at subclasses, which means this
should also handle cases where the user has defined a new subclass that
inherits from one of these three classes.)
