This changes the test output because `VariableDeclarationGroup.toString`
changes to be the one inherited from VariableDeclarationEntry. This
should not affect the output as shown by any front end because
the string to be displayed to the user for a `$@` interpolation comes
from the following column instead.
This avoids using a raw db type.
It is possible for `SuppressionComment` and `SuppressionScope` to have
different locations because `SuppressionScope` defines `hasLocationInfo`
as a new rootdef whereas `SuppressionComment` only responds to
`getLocation` that it inherited. In interpretation of query results, a
`hasLocationInfo` predicate is preferred over `getLocation` if it
exists.
Many classes have been declared with `extends @cfgnode` because they
should be implemented internally as a control-flow node but should not
expose the member predicates of `ControlFlowNode` to their users. After
the transition in a1e44041e it became mandatory to convert explicitly
between the `Element`-derived `ControlFlowNode` and the raw dbtype
`@cfgnode`, and that commit inserted numerous such conversions as a
result of having all those classes that did not derive from `Element` in
the standard library.
It was also confusing and error-prone that the libraries implementing
`ControlFlowNode` referred to `ControlFlowNode`. This seemingly cyclic
reference worked out because the libraries did not call the predicates
on `ControlFlowNode` whose implementation they were part of.
Both these problems are now solved by adding a new class
`ControlFlowNodeBase extends Element` that should be used in preference
to `@cfgnode` everywhere. This class is for exactly those use cases
where `@cfgnode` should be seen as an `Element` without having too many
member predicates on it.
The classes that move from extending `@cfgnode` to extending
`ControlFlowNodeBase` are: `BasicBlock`, `AdditionalControlFlowEdge`,
`DefOrUse`, `SsaDefinition`, `SubBasicBlock` and `RangeSsaDefinition`.
These previously had to define their own `toString` rootdef, which
typically had some dummy string as result (like `"BasicBlock"`), but now
their `toString` is part of the `Element` rootdef and should not be
overridden otherwise `Element.toString` will sometimes have multiple
results. Removing these dummy `toString` predicates had some effects on
the tests that are included in this commit.
The `getLocation` family of predicates is affected like `toString`, but
the situation is slightly different. Some of these classes had genuinely
useful alternative definitions of locations. Fortunately, they all used
`hasLocationInfo`, which is preferred over `getLocation` by the QL
engine. Because `Element` does not define `getLocationInfo`, each class
can create its own rootdef of this predicate like before.
Now that opcodes are in their own module that isn't imported into the global namespace, `Opcode::Call` no longer conflicts with `Call` from the ASTs. I've renamed `Opcode::Invoke` to `Opcode::Call`.
The presence of abstract predicates on this class made it hard to
specialize it, and this is one of the reasons why the raw db-type
`@cfgnode` is often used in preference to `ControlFlowNode`.
PrintAST.ql orders the functions by location, then in lexicographical order of the function signature. This is supposed to ensure a stable ordering, but functions without a location were not getting assigned an order at all.
ZipSlip can be avoided by checking that the combined and resolved
path `StartsWith` the appropriate destination directory. Refine the
`StartsWith` sanitizer to:
* Consider expressions guarded by an appropriate StartsWith check to be
sanitized.
* Consider a StartsWith check to be inappropriate if it is checking the
result of `Path.Combine`, as that has not been appropriately resolved.
Tests have been updated to reflect this refinement.
Use the GetFileName call as a sanitizer, rather than an argument to that
call. It is the _result_ of the GetFileName call which should be
considered sanitized. By using the argument, we can spuriously suppress
use-use flow. Consider:
```
var path = Path.Combine(destDir, entry.GetFullName());
var fileName = Path.GetFileName(path);
log("Extracting " + fileName);
entry.ExtractToFile(path);
```
Previously, the `ExtractToFile(path)` call would not have been flagged,
because the `path` argument to `GetFileName` was considered sanitized,
and that argument formed a use-use pair with the `path` argument to
`ExtractToFile`. Now, this result would be flagged because only the
result of the `GetFileName` call is considered sanitized.
This file is used by the `sync-identical-files.py` pull-request check in
our internal repo, which can hopefully soon start running on this repo
as well. This initial commit moves over all the file group definitions
whose files are entirely within this repository.
This change is not synchronized with the internal repo, so the file
groups will appear in both repositories until they sync up. That should
not cause any problems.
The `definitelyHandles()` predicate calculates the relation for all exception
types, not just the ones that can actually be thrown (no automatic magic).
This commit inlines the definition of `definitelyHandles()` to get the proper
context (manual magic).
