[Bug]: Dyno reports the wrong location for minimal modules

[jabraham17]

I am finding that with the standard library enabled, that Dyno reports incorrect locations for minimal modules.

The following chapel-py program shows the problem

import chapel

c = chapel.Context()
c.set_module_paths([], [])
asts = c.parse("modules/minimal/internal/CTypes.chpl")
mod = asts[1]
loc = mod.location()
print("root is:", mod)
print("Location is:", loc)
print("dump", mod.dump())

In this example, mod.dump() shows the correct AST for modules/minimal/internal/CTypes.chpl, but the location is printed as modules/standard/CTypes.chpl.

I tried this with a module outside the "blessed" path, using Sort.chpl as a proxy. This could not replicate the issue, so I think this error is specific to two internal modules of the same name (as is the case with minimal modules)

This causes problems for some chplcheck lint rules which rely on location information for a Module (like LineLength)

[mppf]

How did minimal modules become involved originally with the problem with chplcheck that led you to discover this?

[jabraham17]

This was found by running chplcheck modules/minimal/internal/CTypes.chpl. This was not done intentionally, @DanilaFe has chplcheck running in his editor and opened modules/minimal/internal/CTypes.chpl and found a bunch a incorrect lint warnings, caused by this bug

[DanilaFe]

I bet the issue is more general: if you open any module named the same as a standard module (but not the standard module Chapel would load), you'd run into this.

[mppf]

The way we have library loading implemented right now, something in the standard module search path takes priority, and we don't have a facility for two modules with the same name.

So I would expect that the best case in this situation would be that chplcheck gives an error that it doesn't have the ability to check modules/minimal/internal/CTypes.chpl (or any such file duplicative of the standard library).

[jabraham17]

something in the standard module search path takes priority, and we don't have a facility for two modules with the same name.

Note that I tried this with something like "mymod/Sort.chpl" and that was fine, both the module contents and file location were reported correctly. And I find it puzzling that with CTypes, the module contents are correct but the file location is wrong. So we are parsing the right file, but then when mapping the ID of CTypes we end up with the wrong module.

[mppf]

FWIW, I would expect problems with "mymod/Sort.chpl" that you just haven't uncovered yet. CTypes might be behaving differently due to it being more important when compiling more internal code.