|std:///util/Reflective.rsc|(6610,2,<168,84>,<168,86>): |std:///util/Reflective.rsc|:168,84: "No module name found for |std:///Exception.rsc|(0,3651,\<1,0\>,\<122,3\>);\nsrcs=[|file:///Users/jurgenv/git/drambiguity/src|];\nlibs=[|lib://rascal|,|target://salix-core|,|target://salix-contrib|]"
at getModuleName(|std:///util/Reflective.rsc|(5261,1354,<134,0>,<169,1>))
at getModuleName(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(3179,64,<87,11>,<87,75>))
at complete(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(5757,126,<130,18>,<130,144>))
at getImportAndExtendGraph(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(6022,154,<135,11>,<135,165>))
at rascalTModelForLocs(|lib://rascal-core/lang/rascalcore/check/Checker.rsc|(9845,7581,<209,8>,<362,5>))
at check(|lib://rascal-core/lang/rascalcore/check/Checker.rsc|(21389,97,<464,38>,<464,135>))
at $shell$(|main://$shell$|)
Here we see that |std:///| is not even on the source path. And so getModuleName can't find the module for it. The |std:///| prefix is used by the path rewriter just before the rascal standard library is deployed.
the type checker should not crash on this, but it should report an error and not generate a whole bunch of downstream unresolved names and types
projects that have |lib://rascal| on the libs path and not |std:///| need some kind of fix, because this is now unworkable.
Describe the bug
Here we see that
|std:///|
is not even on the source path. And sogetModuleName
can't find the module for it. The|std:///|
prefix is used by the path rewriter just before the rascal standard library is deployed.|lib://rascal|
on the libs path and not|std:///|
need some kind of fix, because this is now unworkable.