The `Expr.getType` predicate returns a pointer type since that's the
type of the `new`-expression as a whole. To find the class type, we use
`NewExpr.getAllocatedType`.
This commit reduces the number of alerts in a Qt snapshot from 229 to
51, and it removes the two false positives in
https://github.com/Subsurface-divelog/subsurface.
These type checks were overlapping with `assignOperatorWithWrongType` is
are no longer needed now that `assignOperatorWithWrongType` is improved.
They were causing FPs and misleading error messages on uninstantiated
templates.
Adding this call to `getUnspecifiedType` makes the error message better
in the presence of typedefs and qualifiers on an assignment operator
return type. It's also needed to avoid losing valid results in the
commit that comes after this.
This rule, named "No virtual destructor", was supposed to be superseded
by `cpp/virtual-destructor` in 0c796de83, but that commit didn't
actually disable this rule, so both rules are now active in the LGTM
suite.
This commit disables the rule by removing `@precision`. We're still
discussing the best way to disable rules that are precise and valid but
not universally applicable. For now, removing `@precision` is consistent
with how we're keeping most other JSF queries from appearing on LGTM.
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.
