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).
Commit a1e44041e made `XMLFile` no longer extend `File`. I'm guessing
this was necessary in the branch where `File` was an IPA-typed `Element`
and `XMLFile` was not, but it broke compilation of some of our internal
queries.
I introduced some unnecessary base classes in the `TranslatedExpr` hierarchy with a previous commit. This commit refactors the hierarchy a bit to align with the following high-level description:
`TranslatedExpr` represents a translated piece of an `Expr`. Each `Expr` has exactly one `TranslatedCoreExpr`, which produces the result of that `Expr` ignoring any lvalue-to-rvalue conversion on its result. If an lvalue-to-rvalue converison is present, there is an additional `TranslatedLoad` for that `Expr` to do the conversion. For higher-level `Expr`s like `NewExpr`, there can also be additional `TranslatedExpr`s to represent the sub-operations within the overall `Expr`, such as the allocator call.
These expressions are a little trickier than most because they include an implicit call to an allocator function. The database tells us which function to call, but we have to synthesize the allocation size and alignment arguments ourselves. The alignment argument, if it exists, is always a constant, but the size argument requires multiplication by the element count for most `NewArrayExpr`s. I introduced the new `TranslatedAllocationSize` class to handle this.
The Metrics folder has a queries.xml file which is required when
building a full distribution, as the Metrics folder gets copied into
odasa-csharp-metrics directory. However, in QL for Eclipse this doesn't
compile because it prevents import lookup at the top level. Modifying
the qlpath file to include the top-level directory on the library path
fixes the problem.
