Since predicate name `import` is not allowed, I adopted `importNode` as it sort
of matches what `exprNode` does.
---
Due to only using `importMember` in `os_attr` we previously didn't handle
`import os.path as alias` :|
I did creat a hotfix for this (https://github.com/github/codeql/pull/4446), but
in doing so I realized the core of the problem: We're exposing ourselves to
making these kinds of mistakes by having BOTH importModule and importMember, and
we don't really gain anything from doing this!
We do loose the ability to easily only modeling `from mod import val` and not
`import mod.val`, but I don't think that will ever be relevant.
This change will also make us to recognize some invalid code, for example in
import os.system as runtime_error
we would now model that `runtime_error` is a reference to the `os.system`
function (although the actual import would result in a runtime error).
Overall these are tradeoffs I'm willing to make, as it does makes things simpler
from a QL modeling point of view, and THAT sounds nice 👍
This is not a very good test for showing that we don't handle direct imports,
but it was the best I had available without inventing something new. It's very
fragile, since any of these would propagate taint (due to handling all `join`
calls as if the qualifier was a string):
ospath_alias.join(ts)
ospath_alias.join(ts, "foo", "bar")
But this test DOES serve the purpose of illustrating that my fix works :D
The number of candidate bounds during the main `SimpleRangeAnalysis`
recursion was in principle always exponential in the size of the
program, but in practice it did not get out of hand when only `+` and
`-` operations were supported. Now that `*` is also supported, the range
analysis started timing out on the SinaMostafanejad/OpenRDM project. The
problematic expressions in that project are of the form
a*x*x*x + b*x*x + c*x + d
where most of the variables involved are recursive definitions and are
therefore likely to have a large number of candidate bounds.
The fix here is to identify those few binary operations that are most
likely to cause an explosion in the number of bounds and apply widening
to them. Previously, widening was only applied at definitions.
