use statement does not find renamed import

[mppf]

I was expecting the following program to compile and run, because the use B brings in something named CC which actually refers to C; so use CC should work. However it does not.

module A {
  use B;
  use CC;

  var x = cvar;

  proc main() {
    writeln(x);
  }
}

module B {
  public import C as CC;
}

module C {
  var cvar: int = 1;
}

cc.chpl:3: error: Cannot find module or enum 'CC'

There is a variation that fails in a similar way but does not use an as statement:

module A {
  use B;
  use CC;

  var x = cvar;

  proc main() {
    writeln(x);
  }
}

module B {
  module C {
    module CC {
      var cvar: int = 1;
    }
  }

  public import this.C.CC;
}

This one also fails in a similar way with a public use instead:

module A {
  use B;
  use CC;

  var x = cvar;

  proc main() {
    writeln(x);
  }
}

module B {
  module C {
    module CC {
      var cvar: int = 1;
    }
  }

  public use C;
}

[mppf]

Here is a program doing a similar thing, but without an import that renames:

module A {
  use B;
  use CC;

  var x = cvar;

  proc main() {
    writeln(x);
  }
}

module B {
  module CC {
    var cvar: int = 1;
  }

  public import this.CC;
}

This one compiles and runs. But, the compiler here can just be using the module CC declaration itself and ignoring the public import.

[lydia-duncan]

I kinda suspect these are two separate issues. My expectation is that the renaming one is a result of the use/import resolution diverging from scope and function resolution (and that a way of unifying those further would be a good idea).

The fact that it doesn't work for modules made visible by a public use or import without renaming is concerning and surprising, and I wonder if it failed in that way last release or if this is a result of recent changes (either your PR or some of my bug fixes during issues week)

[mppf]

All 3 examples in the OP fail with 1.26. (Also I don't think we necessarily need to fix this in the production compiler - we can just focus on getting it working in dyno).

[lydia-duncan]

Also I don't think we necessarily need to fix this in the production compiler - we can just focus on getting it working in dyno

I'm definitely okay with that, especially since it seems like we're close to relying on that portion of the dyno compiler

[lydia-duncan]

We should definitely file them as futures, though, so we don't forget that we want to fix them