Second batch of test reblessings, capturing changes in result content
(not just toString labels):
- Framework taint/concept tests (fastapi, sqlalchemy, aiohttp, lxml,
stdlib, django-orm): mostly gained MISSING-tainted annotations where
the new dataflow no longer reaches sinks. Some are real taint
regressions; left as documented failures for follow-up.
- Exception-handler tests (CWE-209-StackTraceExposure, EmptyExcept,
CatchingBaseException, IncorrectExceptOrder, FileNotAlwaysClosed,
FindSubclass/Find, Statements/exit/UseOfExit): the no-raise shared CFG
abstraction does not emit ExceptionSuccessor abrupt-completion edges
from arbitrary expressions, so except-handler bodies (and their
exception target Names) are statically dead. Tracked separately under
cfg-modelling-exceptions.
- Dataflow-path / control-flow node toString polish across the security
query suite (PathInjection, CodeInjection, UnsafeUnpacking,
UnsafeUsageOfClientSideEncryptionVersion, RequestWithoutValidation,
ReflectedXss, CallGraph): simple-leaf nodes now stringify as their
AST text instead of 'After X'.
- SSA / call-graph improvements (CmpTest, CallGraph/InlineCallGraphTest):
fewer SSA mismatches between new and old; two previously-MISSING tt=
annotations resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
In reality, we only want to model this as a `rest_framework.response.Response`, since our .qll modeling is more precise for rest-framework responses than if we also modeled it as a basic django http response. (specifically, that default mime-type handling is way different).
I fixed it in both predicates... I think we might still be able to remove
`newDirectAlias` -- but with it being better, it will allow us to better test if `newImportAlias` actually cover everything we need!
Due to the 'only model most specific spec' logic highlighted in previous
commit, I'm changing away from MethodView/View, and use Django view instead.
In practice this shouldn't matter at all, but for writing tests it would
have been a nice fix to only have the "same name but more specific"
logic apply when it's the same _definition_ location. We used to have
this information available, but right now we don't... so instead of
spending a lot of time rewriting the core library, I simply used a
different class :D :O :(
