Use f-strings instead of `+` concatenation, remove `set unstable`
(all previously unstable features are now stable), and add `[parallel]`
to swift `extra-tests` recipe.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use env("python_version", "3") so that when the parent just process
exports the variable, nested just calls (via language_tests.py) pick
it up.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
By limiting the results to the class that actually defines the `__del__`
method, we eliminate a bunch of FPs where a _subclass_ of such a class
would also get flagged.
For module-level metaclass declarations, we now also check that the
right hand side in a `__metaclass__ = type` assignment is in fact the
built-in `type`.
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).
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.
The fix may look a bit obscure, so here's what's going on.
When we see `from . import helper`, we create an `ImportExpr` with level
equal to 1 (corresponding to the number of dots). To resolve such
imports, we compute the name of the enclosing package, as part of
`ImportExpr.qualifiedTopName()`. For this form of import expression, it
is equivalent to `this.getEnclosingModule().getPackageName()`. But
`qualifiedTopName` requires that `valid_module_name` holds for its
result, and this was _not_ the case for namespace packages.
To fix this, we extend `valid_module_name` to include the module names
of _any_ folder, not just regular package (which are the ones where
there's a `__init__.py` in the folder). Note that this doesn't simply
include all folders -- only the ones that result in valid module names
in Python.
This join had badness 1127 on the project FiacreT/M-moire, producing ~31
million tuples in order to end up with only ~27k tuples later in the
pipeline. With the fix, we reduce this by roughly the full 31 million
(the new materialised helper predicate accounting for roughly 130k
tuples on its own).
Co-authored-by: Mathias Vorreiter Pedersen <mathiasvp@github.com>
