Turns out we were not setting the `is_async` field on anything except
`async for` statements. This commit makes it so that we also do this for
`async def` and `async with`, and adds a test that this produces the
same behaviour as the old parser.
Found when parsing `Lib/test/test_coroutines.py` using the new parser.
For whatever reason, having `await` be an `expression` (with an argument
of the same kind) resulted in a bad parse. Consulting the official
grammar, we see that `await` should actually be a `primary_expression`
instead. This is also more in line with the other unary operators, whose
precedence is shared by the `await` syntax.
Quoting the Python documentation (last paragraph of
https://docs.python.org/3/reference/lexical_analysis.html#escape-sequences):
"Even in a raw literal, quotes can be escaped with a backslash, but the
backslash remains in the result; for example, r"\"" is a valid string
literal consisting of two characters: a backslash and a double quote;
r"\" is not a valid string literal (even a raw string cannot end in an
odd number of backslashes)."
We did not handle this correctly in the scanner, as we only consumed the
backslash but not the following single or double quote, resulting in
that character getting interpreted as the end of the string.
To fix this, we do a second lookahead after consuming the backslash, and
if the next character is the end character for the string, we advance
the lexer across it as well.
Similarly, backslashes in raw strings can escape other backslashes.
Thus, for a string like '\\' we must consume the second backslash,
otherwise we'll interpret it as escaping the end quote.
A somewhat complicated solution that necessitated adding a new custom
function to `tsg-python`. See the comments in `python.tsg` for why this
was necessary.
Surprisingly, the new parser did not support these constructs (and the
relevant test was missing this case), so on files that required the new
parser we were unable to parse this construct.
To fix it, we add `list_pattern` (not to be confused with
`pattern_list`) as a `tree-sitter-python` node that results in a `List`
node in the AST.
Turns out, `except*` is actually not a token on its own according to the
Python grammar. This means it's legal to write `except *foo: ...`, which
we previously would consider a syntax error.
To fix it, we simply break up the `except*` into two separate tokens.
That is, the `*T` in `def foo(*args : *T): ...`.
This is apparently a piece of syntax we did not support correctly until
now.
In terms of the grammar, we simply add `list_splat` as a possible
alternative for `type` (which could previously only be an `expression`).
We also update `python.tsg` to not specify `expression` those places (as
the relevant stanzas will then not work for `list_splat`s).
This syntax is not supported by the old parser, hence we only add a new
parser test for it.
This is primarily useful for ensuring that errors where a node does not
have an appropriate context set in `python.tsg` actually have an effect
on the pass/fail status of the parser tests. Previously, these would
just be logged to stdout, but test could still succeed when there were
errors present.
Also fixes one of the logging lines in `tsg_parser.py` to be more
consistent with the others.
Extends our modelling to partially cover the behaviour of
`copy.replace`. In particular, we model this in two ways:
Firstly, we extend the existing Models-as-Data row for `copy` and
`deepcopy` to also cover `replace`. This means that we treat the result
of `replace` as containing all of the fields of the original object.
This is somewhat _more_ than we want, as strictly speaking the fields
that are overwritten should _not_ propagate flow through the `replace`
call, but currently we don't have a good way of modelling this blocking
of flow.
Secondly, we add a flow summary that adds flow from named arguments of
the `replace` call to the corresponding fields on the base object. This
ensures that we at least have the new flow arising from the `replace`
call.
Note that the flow summary adds this flow for _all_ named arguments of
_all_ `replace` calls throughout the codebase. However, since any
particular `replace` call will only populate a subset of these (the
subset consisting of exactly those named arguments that are in that
particular call), this does not cause any unwanted crosstalk between
different `replace` calls.§
Demonstrates the somewhat more ergonomic way to use
`getMaDRepresentation` when specifying summaries.
Note that this slightly extends the previous definition, in that
`DictionaryContentAny` is now _also_ propagated by a call to the
`.copy()` method, but I think this is correct.
This adds a convenient way of getting the Models-as-Data representation
of a particular type of content. This avoids repeating the same
construction over and over in our various summaries. Currently this is
defined for all types of content except the captured variable content,
which to my knowledge doesn't have any representation in Models-as-Data.
This test demonstrates the current state of affairs: that `copy.replace`
essentially blocks all flow of taint through it, because it has not been
modelled yet.
Adds up- and downgrade scripts for the support for type parameter
defaults.
In the upgrade direction we do nothing, matching the behaviour of
`getDefault` not having a result for old databases.
In the downgrade direction, we explicitly remove the relevant child (via
the `py_exprs` database relation) for `TypeVar`, `TypeVarTuple`, and
`ParamSpec` parameters.
Note that this still includes the somewhat puzzling parsing of
`Spam[**P2]` as an exponentiation with an empty left hand side. When we
fix that bug, we should also update this test to contain actually valid
syntax.
There was an errant `ql` in the relevant paths, a leftover from the move
from the internal repo. Also, we can no longer rely on an intree version
of the CodeQL CLI, so from now on we'll just assume it's present in the
path. (On Codespaces, `gh codeql` is a decent replacement, especially if
using the `install-stub` functionality.
Two new files -- alloc.h and array.h -- suddenly appeared. Presumably
they are used by the somewhat newer version of tree-sitter. To be safe,
I included them in this commit.
