Extends the mechanism introduced in
https://github.com/github/codeql/pull/18030
to behave the same for _all_ `MatchLiteralPattern`s, not just the ones
that happen to be the constant `True` or `False`.
Co-authored-by: yoff <yoff@github.com>
Observed on some test files in Nuitka/Nuitka, having `break` and
`continue` outside of loops in Python is (to Python) a syntax error, but
our parser happily accepted this broken syntax.
This then caused issues further downstream in the control-flow
construction, as it broke some invariants.
To fix this we now skip the code that would previously fail when the
invariants are broken.
Co-authored-by: yoff <yoff@github.com>
Once again, the interaction between anchors and extras (specifically
comments) was causing trouble.
The root of the problem was the fact that in `a[b]`, we put `b` in the
`index` field of the subscript node, whereas in `a[b,c]`, we
additionally synthesize a `Tuple` node for `b,c` (which matches the
Python AST).
To fix this, we refactored the grammar slightly so as to make that tuple
explicit, such that a subscript node either contains a single expression
or the newly added tuple node. This greatly simplifies the logic.
Adds a query that counts the number of type annotations of various
kinds. Intended to be used with something like MRVA to inform our
modelling decisions.
Currently the query counts the following "interesting" types in addition
to the total number of types:
- Built-in types (which are less likely to be interesting from a
modelling perspective)
- Forward declarations (i.e. annotations inside strings) which will
require a fair bit of QL machinery to interpret.
- Simple types (stuff like `foo` or `foo.bar.baz`)
- Optional types (stuff like `Optional[foo]` which from a modelling
perspective should likely be treated the same as `foo`)
- Complex types (anything that contains more complex type constructions
such as instantiations of generic types)
