I’m in the process of migrating a project from 1.2 to 1.3. My SDF3 files parse OK (after lifting them, which worked well) but I get the following when trying to build:

call-onsave:
        [java] Calling on-save handler for: /Volumes/HDD/pdm/Workspaces/Spoofax-1.3/CL/syntax/CL-Funcons.sdf3
        [java] Calling on-save handler for: /Volumes/HDD/pdm/Workspaces/Spoofax-1.3/CL/syntax/CL-Lexical.sdf3
        [java] Calling on-save handler for: /Volumes/HDD/pdm/Workspaces/Spoofax-1.3/CL/syntax/CL-Syntax.sdf3
        [java] generating for CL-Funcons.sdf3
        [java] generating for CL-Lexical.sdf3
        [java] generating for CL-Syntax.sdf3
        [java] [ TemplateLang | error ] No pp entry found for: (3,["sdfProduction"])
        [java] [ TemplateLang | error ] Cannot rewrite to box: 
        [java]         sdfProduction(sort("CL-expr"),rhs([sort("CL-expr"),lit("\".\""),sort("CL-label")]),no-attrs)
        [java] [ TemplateLang | error ] No pp entry found for: (17,[[]])
        [java] [ TemplateLang | error ] Cannot rewrite to box: 
        [java]         [sdfProduction(sort("CL-expr") ...

Looking at trans/pp.str I see that prettyprint-SDF-start-symbols is flagged as not defined. The file starts:

module pp

imports

	libstratego-gpp
	lib/runtime/refactoring/-
	src-gen/pp/CL-pp

rules
	
  pp-CL-string =
    prettyprint-SDF-start-symbols
    ; !V([], <id>)
    ; box2text-string(|120)

Perhaps it’s related to CL-Syntax.sdf3 using context-free syntax productive format productions (no templates)?

Peter

Submitted by Peter Mosses on 19 November 2014 at 18:35

Hi Peter, could you attach the file (s) that is (are) causing the issue?
prettyprint-SDF-start-symbols is generated from the start symbols of your grammar, that I guess is defined in CL.sdf3 according to your import src-gen/pp/CL-pp.

Hi Eduardo, I’ve now added a zip of all the SDF3 files in the syntax folder (except for Common.sd3, which I’m not using).

Hi Peter, I think I found the issue and fixed it. Some remarks:

• You should import the file that contains the start symbols of your grammar in trans/pp.str. This should probably be included somewhere in the documentation anyway. The strategy prettyprint-SDF-start-symbols is generated from the symbols in the context-free start-symbols section, therefore importing a file that contains this section will fix the error in the editor.

• The file Stratego-CL.sdf3 contains parameterized modules and sorts and they are not supported in SDF3. They are probably supported syntactically because SDF3 grammar contains SDF2 grammar, but building the project will fail at some point as you won’t get the signatures or pretty-printer out of it. You can keep it as an SDF2 file and import it from your SDF3 files just fine as long as the SDF2 file is not defining a parameterized module.

• The issue was actually something that I did not know until two weeks ago. There is a feature in SDF2 priorities that allows you to specify the argument of a production in which you are applying the priority (if I understood it correctly, it means that). This is a feature that was added later in SDF2 development and it was not included in the previous SDF3 implementation, so I ended up missing it when translating SDF3 back to SDF2 to generate the parse table.

I committed this fix and some more (such as https://yellowgrass.org/issue/Spoofax/929) to nightly, but as you said, it would be nice to have them in a stable release. We are going to release 1.3.1 soon, which will include them.

Many thanks for the diagnosis and the quick fix. After moving the start symbols to CL.sdf3 and commenting-out the offending priorities in CL-Syntax, the project now builds OK.

As expected, I now get ambiguities when parsing CL programs. However, I also get an internal jsglr.clent.FilterException: “Runtime exception when applying filters”. This arises when trying to parse test/example.ml in the attached CL.zip export (which also includes my updated syntax files). I hope that issue will disappear when 1.3.1 is released and I can reinstate the required priorities, but I thought I’d better mention it now, in case it’s unrelated.

I’m closing this for now to add it to the changelog of the release. Please comment again if you get errors after updating in the future.
I will also try your setup as it is now because I think this parse error should not occur even if your priorities are wrong.