Unfortunately, it is not sufficient to represent a globally-scoped qualified name like $::A::B as simply an Xtext QualifiedName with an initial segment of "$". That is because '$'::A::B is also a legal qualified name, but, in this case, '$' is an actual name, not the global scope qualifier. Thus:

package A {
    package '$' {
        package A {
            part def B; // The qualified name resolves here...
        }
    }
    part def B { // ... not here.
        part x : '$'::A::B;
    }
}

I have revised the implementation to use a new GlobalScopeQualifiedName to represent a globally-scoped qualified name. I also updated the KerML Xpect tests so they also include qualified names that start with '$', to check that these now also resolve correctly (which they did not before). The name resolution for a globally-scoped qualified name remains essentially the same, however.

Please review.

@TheKorpos
I realized there is a much simpler way to do this: just use a specific string to represent the GLOBAL_SCOPE_SYMBOL as the first segment, and check for this using == rather than equals. This work as longs as we do not turn on the option to intern segment strings.

I have implemented this option on the ST6RI-830-1 branch. Please review, and, if you concur, I will move it to he ST6RI-830 branch.

@seidewitz

Unfortunately, it is not sufficient to represent a globally-scoped qualified name like $::A::B as simply an Xtext QualifiedName with an initial segment of "$". That is because '$'::A::B is also a legal qualified name, but, in this case, '$' is an actual name, not the global scope qualifier.

Oh yes, I forgot that '$'::A::B becomes $::A::B during qn conversion. Thank you for the fix.

check for this using == rather than equals

This sounds like a pretty good idea and it is much simpler. Usually I'm a little bit worried using static fields like this. I have seen some nasty bugs where the same class was loaded multiple times in multi-threaded environments. I performed a smoke test in Eclipse and the instance is the same across threads so this is probably fine in our case. We'd also have to be careful how we (deep) copy qualified names and how we construct them moving forward.

I think prefer the first version still. It is more explicit aobut this capability and feels more correct to me but if you really like the simpler solution I don't see any imminent issues with it.

I decided to go with the simpler approach. However, I revised QualifiedNameUtil to abstract the representation of globally scoped qualified names. So, if we decide to switch back to the other approach, we can do that without any change to the scope code.

I have pushed the other approach (using GlobalScopeQualifiedName) to branch ST6RI-830-2 and force-pushed ST6RI-830 to be the same as ST6RI-830-1 with the simpler approach.