Rascal-core failes and mentions not finding std:///List.rsc
#13
Assignees
Labels
bug
Something isn't working
Comments
DavyLandman
changed the title
std:///List.rsc std:///List.rsc
|
Just checking: It's the rascal maven plugin failing to run the compiler code from rascal-core and typepal, using the interpreter, which isn't able to load the List module from |
|
So there are two pathConfigs here. One is for configuring and loading the Compiler itself. One is for passing to the compiler once it's loaded, with the dirty modules list. |
|
It might be a case of the Rascal project itself open in VScode but its resources in the target folder out of date. Could you check if removing the project from the workspace helps or running |
|
The inconsistencies you noticed @DavyLandman are all due to the two pathConfigs. Once you distinguish them, it all makes sense. The maven plugin uses the std library that matches the rascal version it depends on, but may use a different library for checking against for the current project. However as long as |
|
Here is the full log: Your questions:
Looks to me this is happening during the typecheck.
True, I tried to focus on the one related to the actual running of the type-check, not loading the type-checker.
This workspace had no rascal open.
For loading, sure, that makes sense. But the pathConfig I pulled out was for type-checking. I guess I understand why we use that So, anyway, adding |
|
Okay, smallest repo case:
module Hello
extend analysis::typepal::TypePal;
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.rascalmpl</groupId>
<artifactId>slow-vscode</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.rascalmpl</groupId>
<artifactId>rascal</artifactId>
<version>0.28.3</version>
</dependency>
<dependency>
<groupId>org.rascalmpl</groupId>
<artifactId>typepal</artifactId>
<version>0.7.9</version>
</dependency>
</dependencies>
<build>
<resources>
<resource>
<directory>.</directory>
<filtering>false</filtering>
<includes>
<include>META-INF/RASCAL.MF</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/rascal</directory>
<filtering>false</filtering>
</resource>
</resources>
<!-- define plugins for the nested projects -->
<plugins>
<plugin>
<groupId>org.rascalmpl</groupId>
<artifactId>rascal-maven-plugin</artifactId>
<version>0.14.5</version>
<configuration>
<bin>${project.build.outputDirectory}</bin>
<srcs>
<src>${project.basedir}/src/main/rascal</src>
</srcs>
<enableStandardLibrary>false</enableStandardLibrary>
</configuration>
<executions>
<execution>
<id>it-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>it-package</id>
<phase>prepare-package</phase>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>usethesource-releases</id>
<url>https://releases.usethesource.io/maven/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>usethesource-releases</id>
<url>https://releases.usethesource.io/maven/</url>
</pluginRepository>
</pluginRepositories>
</project>
project: slow-vscode.zip output of mvn clean compile: |
|
Note, also if I run this inside a REPL pointed at the it also fails: |
|
I don't understand yet why the typechecker is looking for module names of source files for binary dependencies. So that's what I'll start researching first. The standard library is a binary dependency on the lib path (the Rascal project jar) and so module names like |
|
Hypothesis/wild idea:
|
|
Checking out that project on a fresh linux container shows the same problem. So I can rule out it's something specific to my machine. |
|
If I turn back See the path config: Also, I've seen this fail for |
|
FWIW: I've seen the "No module name found for <_>" message before when the type checker tries to read tpl files created by an older version of typepal (e.g., saving a module in an IDE after having done |
|
experiment time:
(note that typepal was build with 0.23.0 & 0.8.1) So it seems that since typepal was build with 0.8.1, which linked it to rascal 0.23.0, you get into problems if you run it with a too new of a rascal.jar. Either since it flows from the rascal-maven-plugin (where it's standard lib is used) or if you define your own version of rascal. How do we solve this issue? Typepal as released does not work with the most recent versions of rascal, nor the most recent versions of the rascal-maven-plugin. Should we release a new build of typepal just so that we can link to it again? |
|
So this should work: while this path config should fail: |
|
@PaulKlint we should figure out a way soon-ish to make source compatible Rascal modules in the standard library also be binary compatible .tpl files. For this particular case we can fix the rascal version dependency in rascal-core and typepal, such that the maven plugin, typepal, and the rascal-core are referring to the same version, but more and more (DSL) components will be compiled against different versions of the standard library and turn out to be incompatible only on the .tpl level while they work fine otherwise. |
|
@jurgenvinju but in this case, some source files might have changed right? Some of the modules that typepal imports might have gained new functions. So that would become a bit harder to support right? |
|
@DavyLandman If a typepal module evolves in a backward-compatible way, such as adding new functions, then it would be natural to expect that older clients can link to the new binary. They would not use the new functions, but they would expect the older functions still to work. In other words the new binary .tpl file (and later also .class file) is "backwards compatible". |
|
typepal release 0.8.0 has solved --this instance of-- the problem. |
|
Hi - I'm running into a similar problem. This instance however already occurs on inclusion (not extention) of a module, namely This error was introduced on a larger project when I updated the rascal and rascal-maven-plugin versions. However, after undoing those changes in the pom.xml, the error remains, which is very frustrating. I have reset my repository to a clean state (e.g. removed target/) but this still doesn't resolve the issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
note:
and:
PathConfig:
in the pom.xml:
... <dependencies> <dependency> <groupId>org.rascalmpl</groupId> <artifactId>rascal</artifactId> <version>0.28.2</version> </dependency> <dependency> <groupId>org.rascalmpl</groupId> <artifactId>rascal-lsp</artifactId> <version>2.11.4</version> </dependency> <dependency> <groupId>org.rascalmpl</groupId> <artifactId>typepal</artifactId> <version>0.7.9</version> </dependency> </dependencies> ... <build> <pluginManagement> <!-- define plugins for the nested projects --> <plugins> <plugin> <groupId>org.rascalmpl</groupId> <artifactId>rascal-maven-plugin</artifactId> <version>0.14.1</version> ...Some observations:
lib://rascal/on the libs path, which maps to rascal 0.27.3 since it's the one the maven plugin is running under. and not the rascal lib of the dependencies that the project itself has defined (this can't be right??) note that for typepal it's not doing this, it gets the right typepal jar (instead of thelib:///typepal).But I'm confused of where the
std:///Listcomes from?The text was updated successfully, but these errors were encountered: