I removed this condition in #362, thinking it was covered by the new
conditions on return statements, but it turns out it wasn't in at least
the following cases.
1. Assignment operators that are deleted or marked private in order to
make them inaccessible.
2. Templates whose body was not extracted.
While some of these results are technically valid, they are not nearly
as interesting as the results that this query was designed to produce.
AV Rule 78 has proved too noisy for use on lgtm.com. However, if we make the rule less noisy by, say, allowing a protected destructor to be non-virtual, we're no longer actually enforcing AV Rule 78. Instead, I've copied AV Rule 78 into NonVirtualDestructorInBaseClass.ql, given the new query the `@id` that AV Rule 78 had, and given AV Rule 78 a new JSF-specific `@id`. The new rule allows non-public non-virtual destructors, which is the problem originally reported by an lgtm.com user.
Changes the `forex` range to join on both `this` (the current `ExprEvaluator`) and `ret` (the expected function return value),
so that we look at the relevant return values rather than all interesting functions.
The previous formulation of this predicate caused a CP in snapshots
where a variable had a large number of definitions and also reached a
large number of sub-basic-blocks.
This should fix performance of https://github.com/FrodeSolheim/fs-uae
and https://github.com/libretro/libretro-uae.
The `FlowVar.getAnAccess` predicate is still at risk of CP'ing when a
large group of defs has a large group of uses, but that has not been
observed to happen in practice yet. We would need to make
`localFlowStep` expose phi definitions in order to avoid that risk.
