Added check for scope in structural equivalence (experimental).

[balazske]

I am not sure if this is the best solution but the tests do not fail. The CI tests should be tried. (This is not the final code.)

[martong]

This PR could possibly supersede #625, right?

[balazske]

Maybe the problems only occur when the scope is explicitly written in source code (like at X::A and Y::A only A is checked). So the "written string" could be compared, or only record and namespace decl (but not function). And the scope check can stop at the innermost encountered function.

[martong]

Maybe the problems only occur when the scope is explicitly written in source code (like at X::A and Y::A only A is checked). So the "written string" could be compared, or only record and namespace decl (but not function). And the scope check can stop at the innermost encountered function.

Not necessarily. Consider the below test case, where the same X denotes different types. So I think the problem is NOT limited to qualified names only, thus we have to do the scope check.

TEST_F(StructuralEquivalenceFunctionTest,
    Maci2) {
  auto t = makeNamedDecls(
      "namespace A { class X; } namespace C { using namespace A; void foo(X&); }",
      "namespace B { class X; } namespace C { using namespace B; void foo(X&); }",
      Lang_CXX11);
  EXPECT_FALSE(testStructuralMatch(t));
}

[martong]

There is another case which we should keep in mind:

TEST_F(StructuralEquivalenceFunctionTest,
    Maci) {
  auto t = makeNamedDecls(
      "class X; namespace A { using Y = X; } void foo(A::Y&);",
      "class X; namespace B { using Y = X; } void foo(B::Y&);",
      Lang_CXX11);
  EXPECT_TRUE(testStructuralMatch(t));
}

Here, even if the using decls have different scopes, the underlying type is the same. So if we just compare the scope of two using decls we might end up having the wrong decision. Probably we have to skip using decls from the scope check.

... And I think this case shows that if we just did a string based (USR or the other) comparison of the params then we would falsely report an inequivalence in this case.

... if we did the scope check with string on the underlying types then it would still work

... As a consequence we can't use the scope check in CheckCommonEquivalence, we have to branch based on the node kind and that means we have to put this to the CheckKindSpecificEquivalence.

Update: Just recognized, that the FunctionProtoType stores the canonical types for the arguments, so in this case it will be the X properly. (But I am not sure with other kind of types)