C++: more conservative resolveClass

[jbj]

This PR ensures that resolveClass never returns more than one result and does not attempt to match classes by name if they are templates or are nested in a name space or another class. This fixes the problem on LGTM where ChakraCore analysis went into an infinite loop in getQualifiedName because a class appeared to be nested within itself due to name clashes.

A more thorough fix would be to match classes by fully-qualified name, either with a string or a newtype, but at this point in the release cycle I'm proposing a more minimal fix.

The code change here is the same as in #198, where the CPP-Differences job found no query changes. I've extended the tests to try and show the effects of each commit.

[ian-semmle]

That job compared an ODASA build to itself. I've started another one here: https://jenkins.internal.semmle.com/job/Query-Changes/job/CPP-Differences/412/

[jbj]

Good catch! Does the CPP-Differences job not respect qlSubmoduleShaOverride? Or did I put the wrong SHA?

[ian-semmle]

It doesn't know about qlSubmoduleShaOverride (and if it did, there ought to be a qlSubmoduleShaOverride0 too).

[jbj]

The query changes LGTM. They have the following summary:

=== Overall changes (new / fixed) ===

                                                                           10 / 2


=== Changes per project (new / fixed) ===

linux                                                                      10 / 0
boost                                                                       0 / 2


=== Changes per query (new / fixed) ===

FEfferentCoupling.ql                                                       10 / 1
IncorrectPointerScalingChar.ql                                              0 / 1

I assume the change to IncorrectPointerScalingChar.ql in boost is just the inverse of the change we saw in #7. It's in a file where there are multiple types named implementation but with different qualifiers, and these changes make it so some of them are considered different. I don't understand the code well enough to tell whether it's the old or new behaviour that's correct, but the new behaviour is certainly more conservative, which is the intention with this PR.

The FEfferentCoupling.ql changes are hard to judge. The alerts say "Outgoing dependencies per file too high (N). It is a warning for the value to be higher or equal to 120" for various values of N close to 120. It seems reasonable to me that this query wobbles a bit under these changes.