This commit is yet another step to fixing the order of IR side effect instructions. Instead of having a special `StructorCallSideEffects` class for the call itself, I've introduced a `TranslatedStructorCallQualifierSideEffect` class that shares a bunch of common code with `TranslatedArgumentExprSideEffect`, but handles the case where there's no `Expr` for the qualifier of the constructor call. Because this class uses the same ordering as regular argument side effects, these side effects now appear in the correct order, reads before writes.
The test expectations have changed to reflect the new, correct order.
This commit ensures consistency among all of our qlpacks. Here are the
changes:
1. Ensure only modern references are used (codeql-{lang} is converted to
codeql/{lang}-all or codeql/{lang}-queries where appropriate).
2. Use consistent version numbers. All languages are at 0.0.2 except
javascript, which is 0.0.3.
3. Convert all `libraryPathDependencies` to `dependencies` with version
constraints
4. Dependencies from query packs to other packs are always `"*"` since
these dependencies are always from source and we should get the
latest.
5. Dependencies from codeql/{lang}-lib to codeql/{lang}-upgrades must
be strict since there is a tight connection between the libary
and its relevant upgrades.
This is step two of fixing the ordering of call side effects. This commit refactors the existing `TranslatedSideEffect` class into an abstract `TranslatedSideEffect` class, which contains functionality common to all kinds of side effect, and a concrete `TranslatedArgumentSideEffect` class, which is the implementation of argument side effects. A future commit will add additional concrete classes for conservative call side effects and allocation side effects.
This change has zero diffs to the generated IR.
This is the first step to fixing the order of side effects on call instructions. The goal is to move all side effects (argument side effects, allocation side effects, and conservative call side effects) to be treated as elements in a single sequence of side effects, which will then be handled in a single place similar to how we already handle argument side effects.
There have been multiple reports of false positives from this query over
time. Now that it has `@security-severity 10.0`, these false positives
look even worse.
The query looks purely for calls to functions with certain names, not
at whether the calls happen in a dangerous context. To justify a higher
precision, the query should only flag calls that happen in a thread or
another non-reentrant context.
