Chapel: Fully qualified 'new' fails to resolve when module and type share name

[bradcray]

Summary of Problem

On mail, Brian Rogoff noted that if a module and a type it contains share the same name, using a fully qualified new expression on that type fails with an unresolved call error. This seems similar to issue #8555 (in that both show fragility when using fully-qualified names in new expressions), but different in its behavior.

Steps to Reproduce

Associated Future Test(s):
test/classes/initializers/qualified/modTypeShareName.chpl #8708

Configuration Information

• Output of chpl --version: chpl version 1.17.0 pre-release (e050000)

[benharsh]

I've investigated this a little, and I don't think the issue is restricted to new-expressions nor do I think it's related to initialization. I think the issue lies in the presence of 'use Stack' and later trying to do "Stack.Stack".

For example, I can replace the new-expression line with:

var stack : Stack.Stack;

and still get a compile-time error: unresolved call 'type Stack.Stack'

We still encounter problems with variable names that share the same name as the module:

module Stack {
  var Stack = 100;
}

module M1 {
  use Stack;

  proc main() {
    writeln(Stack.Stack); // just 'Stack' passes fine
  }
}

This program fails to compile with the output:

foo.chpl:8: In function 'main':
foo.chpl:9: error: unresolved call 'int(64).Stack'

Generally, I think what's happening is that the compiler is identifying the first "Stack" to be the variable or type from the module, and not the module itself. If that's the behavior we intended, then perhaps this issue should be about improving the error message?

[lydia-duncan]

I think we should improve the error message.

Our scoping rules say that use statements insert their symbols at scope between the module's symbols and the symbols defined outside it. So when we look for Stack., we search until we first find it and we first find it by going into the use statement.

I think it would be reasonable to emit a warning when a use statement brings in a symbol at the same scope (if the symbol is easily found). That won't help if the name gets hidden due to a symbol in a nested use, but we want to reconsider transitive uses anyways