Switching from Spoofax 2 beta1 to nightly introduces a build failure.

Setup:

Ubuntu 15.10 x86_64
Eclipse Mars.2 Release (4.5.2), Build id: 20160218-0600
Spoofax 2.0.0.20160601-164609-master

Stacktrace:

java.lang.ClassCastException: org.spoofax.terms.StrategoList cannot be cast to org.spoofax.interpreter.terms.IStrategoString
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.extractSortType(Typesmart.java:288) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.processSignature(Typesmart.java:232) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.processModule(Typesmart.java:187) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.processMainStrategoFile(Typesmart.java:141) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.build(Typesmart.java:100) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.Typesmart.build(Typesmart.java:1) ~[org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at build.pluto.builder.Builder.triggerBuild(Builder.java:134) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManager.executeBuilder(BuildManager.java:95) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManager.require(BuildManager.java:328) [pluto-1.9.1.jar:na]
	at build.pluto.builder.Builder.requireBuild(Builder.java:215) [pluto-1.9.1.jar:na]
	at build.pluto.builder.Builder.requireBuild(Builder.java:234) [pluto-1.9.1.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.main.GenerateSourcesBuilder.build(GenerateSourcesBuilder.java:285) [org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.pluto.build.main.GenerateSourcesBuilder.build(GenerateSourcesBuilder.java:1) [org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at build.pluto.builder.Builder.triggerBuild(Builder.java:134) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManager.executeBuilder(BuildManager.java:95) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManager.require(BuildManager.java:328) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManager.requireInitially(BuildManager.java:255) [pluto-1.9.1.jar:na]
	at build.pluto.builder.BuildManagers.build(BuildManagers.java:72) [pluto-1.9.1.jar:na]
	at org.metaborg.spoofax.meta.core.build.LanguageSpecBuilder.plutoBuild(LanguageSpecBuilder.java:291) [org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.meta.core.build.LanguageSpecBuilder.compile(LanguageSpecBuilder.java:132) [org.metaborg.spoofax.meta.core_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.eclipse.meta.build.CompileBuilder$1.run(CompileBuilder.java:49) [org.metaborg.spoofax.eclipse.meta_2.0.0.20160601-164609-master.jar:na]
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.metaborg.spoofax.eclipse.meta.build.CompileBuilder.build(CompileBuilder.java:69) [org.metaborg.spoofax.eclipse.meta_2.0.0.20160601-164609-master.jar:na]
	at org.metaborg.spoofax.eclipse.meta.build.Builder.build(Builder.java:53) [org.metaborg.spoofax.eclipse.meta_2.0.0.20160601-164609-master.jar:na]
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) [org.eclipse.equinox.common_3.7.0.v20150402-1709.jar:na]
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) [org.eclipse.equinox.common_3.7.0.v20150402-1709.jar:na]
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:486) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:405) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:287) [org.eclipse.ui.ide_3.11.0.v20150825-2158.jar:na]
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39) [org.eclipse.core.resources_3.10.1.v20150725-1910.jar:na]
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) [org.eclipse.core.jobs_3.7.0.v20150330-2103.jar:na]

Unfortunately, due to IP I am not sure whether I may publish the code. However, I have a hunch: We are defining multiple productions with the same constructor and same sort but different templates on the right side. When I put these in one sdf3 files, Eclipse gives a warning that this might produce errors during pretty-printing. I thus assume it should not be done.

To conclude:
Issue 1. We should not have multiple productions with the same ctor name (Our error).
Issue 2. When putting one production into one sdf3 file and the other somewhere else, Eclipse doesn't warn about this. (I assume it is still wrong to do so, the warning is just missing. One should add a warning in Spoofax/Eclipse.)
Issue 3. Typesmart crashes without meaningful error message (e.g. at which term/file/signature the error occurred).

Since this is blocking us and I might not be able to fix the root cause (Issue 1), is there a way to disable typesmart checking in nightly?
Thanks in advance and sorry that I cannot give any code...

Submitted by Daniel Lehmann on 1 June 2016 at 21:50

On 1 June 2016 at 22:49 Guido Wachsmuth commented:

Just for completeness: This is the same trace I showed Sebastian this afternoon.


On 2 June 2016 at 01:08 Daniel Lehmann commented:

I tried to reduce the project to a minimal example. A fresh project with this added to an *.str file fails with the same error for me:

module testlang

signature
  constructors
    SomeCtor : ()

whereas this builds fine:

module testlang

signature
  constructors
    SomeCtor : Type

Also, we can compare the Stratego ASTs

Module(
  "testlang"
, [Signature(
     [Constructors([OpDecl("SomeCtor", ConstType(SortTuple([])))])]
   )]
)

(where the build fails) with

Module(
  "testlang"
, [Signature(
     [Constructors([OpDecl("SomeCtor", ConstType(SortNoArgs("Type")))])]
   )]
)

(where it builds fine)

Looking at line 288 where the ClassCastException is thrown (https://github.com/metaborg/spoofax/blob/master/org.metaborg.spoofax.meta.core/src/main/java/org/metaborg/spoofax/meta/core/pluto/build/Typesmart.java#L288)
we see that getSubterm(0) on the SortTuple gives back a list instead of the expected string. Does one need an extra check for kind.equals("SortTuple") before that?


On 2 June 2016 at 17:26 Sebastian Erdweg commented:

I changed the signature extraction to be more defensive (https://github.com/metaborg/spoofax/commit/18264d3590d8212b8277d0775784b2ac9f0dc65c).

  • SortTuple is now correctly parsed into a tuple type (the empty tuple type in your example above)
  • Other ill-formed sorts are rejected with an error during the build. I did not want to touch the Stratego language, which would be necessary for reporting errors in the editor

Does this solve the problem for you?


On 2 June 2016 at 23:06 Daniel Lehmann commented:

Yes, perfect. Thanks alot for this fast fix!


On 3 June 2016 at 00:40 Sebastian Erdweg commented:

Ok, closing.


On 3 June 2016 at 00:40 Sebastian Erdweg closed this issue.

Log in to post comments