I could have sworn I added all of them to the batch, but somehow these slipped through.
Co-authored-by: yoff <lerchedahl@gmail.com>
Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>
I ported the predicates showing difference between points-to and
type-tracking, since it's helpful to see the list of differences,
instead of having to parse expectations!
note how the test file is partially annotated
and those annotations can now be expressed
In this particular test file, absolute line numbers
might have been better than relative ones.
We might remove line numbers altogether,
but should check more querries to see how it looks.
I don't see the value from this, so just going to outright delete it.
(it actually stayed alive for quite some time in the original git history,
but never seemed to be that useful.)
The selected edges is covered by `NormalDataflowTest.ql` now... and
reading the test-output changes in `edges` is just going to make commits
larger while not providing any real value.
I initially created this as a dataflow test, but then realized it could
just be an ESSA test. I cound't find any existing ESSA tests though :|
so created a new dir for it.
A slightly complicated test setup. I wanted to both make sure I captured
the semantics of Python and also the fact that the kinds of global flow
we expect to see are indeed present.
The code is executable, and prints out both when the execution reaches
certain files, and also what values are assigned to the various
attributes that are referenced throughout the program. These values are
validated in the test as well.
My original version used introspection to avoid referencing attributes
directly (thus enabling better error diagnostics), but unfortunately
that made it so that the model couldn't follow what was going on.
The current setup is a bit clunky (and Python's scoping rules makes it
especially so -- cf. the explicit calls to `globals` and `locals`), but
I think it does the job okay.
Note: I kept the modeling using the old approach with type-trackers
instead of `DataFlow::MethodCallNode`.
I would like a meta query for DCA to show sinks before doing this, so I
can be absolutely sure we don't loose out on any important sinks on
this... so will postpone this work to a small one-off task (added to my
todo list).
