Syntax errors in generated ds-signature files
I’m using the pre-packaged Spoofax distribution. Although I don’t have any errors in my sdf3 source files, the generated
*-sig.ds
files insrc-gen/ds-signatures
have syntax errors. These appear to be due to using dashes ‘-
’ in sorts and constructor names. For example:module Funcons/accumulate context-free syntax FCT.F-accumulate = [ accumulate [FCT]]
generates
module src-gen/ds-signatures/Funcons/accumulate-sig signature sorts FCT constructors F-accumulate : FCT -> FCT
and the first
F
in the last line is flagged as an error withSyntax error, not expected here: ' F'
. Similarly:module Funcons/Funcons-Literals context-free start-symbols Start context-free syntax Start = FCT-SEQ ...
generates
module src-gen/ds-signatures/Funcons/Funcons-Literals-sig signature sorts Start FCT-SEQ ...
and the last line is flagged as an error with
Syntax error, not expected here: SEQ
. A clean build of the project also reports errors such asBuildfile: /Volumes/HDD/pdm/SVN/FCT-Editor/build.main.xml [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 [taskdef] rewriting failed, trace: ...
although the build still succeeds.
It appears that
*.ds
files have a more restrictive lexical syntax for sorts and constructors than*.sdf3
files. The moduledynsem/dynsem/syntax/Common.sdf3
includes:lexical syntax INFER = [\-][\-][\-][\-]* ID = [\_a-zA-Z][a-zA-Z0-9\'\_]* LID = [a-zA-Z][a-zA-Z0-9\'\_]* "*"
whereas (I guess) sorts in SDF3 are the same as in SDF2, allowing internal dashes:
module languages/sdf2/syntax/Sorts imports languages/sdf2/syntax/Kernel exports sorts Sort lexical syntax head:[A-Z] -> Sort {cons("one-char")} head:[A-Z] middle:[A-Za-z0-9\-]* last:[A-Za-z0-9] -> Sort {cons("more-chars")}
As a work-around, is there some way to suppress the generation of
Submitted by Peter Mosses on 28 October 2015 at 16:38*-sig.ds
files in projects that don’t use DynSem?
Issue Log
Thank you for reporting this Peter. I’ve pushed a fix to DynSem and a new build (http://buildfarm.metaborg.org/job/spoofax-master/123/) should become available soon. This changes DynSem to add support for hyphens in the names of sorts and constructors. NB: arrow names may not contain hyphens.
Thanks for fixing the DynSem signature parsing issue so quickly. The parse errors in the generated
*.ds
files have indeed disappeared in the 20151030 version.However, I’m still getting lots of internal error reports in a clean build of an editor project. They may be unrelated to that DynSem issue, but any hints for how to suppress or avoid them would be welcome. Here’s how the clean build starts:
Buildfile: /Volumes/HDD/pdm/SVN/FCT-Editor/build.main.xml [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 check-classpath: [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 [taskdef] rewriting failed, trace: [taskdef] editor_analyze_0_0 [taskdef] editor_analyze_0_0 [taskdef] report_with_failure_0_1 [taskdef] report_failure_0_2 [taskdef] SRTS_EXT_fatal_err_0_2 check-classpath.helper: call-onsave: [delete] rewriting failed, trace: [delete] editor_analyze_0_0 [delete] editor_analyze_0_0 [delete] report_with_failure_0_1 [delete] report_failure_0_2 [delete] SRTS_EXT_fatal_err_0_2 [java] Calling on-save handler for: /Volumes/HDD/pdm/SVN/FCT-Editor/syntax/FCT.sdf3 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] Calling on-save handler for: /Volumes/HDD/pdm/SVN/FCT-Editor/syntax/cbs-gen/Funcons/Funcons-Library.sdf3 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] Calling on-save handler for: /Volumes/HDD/pdm/SVN/FCT-Editor/syntax/cbs-gen/Funcons/Funcons-Literals.sdf3 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] Calling on-save handler for: /Volumes/HDD/pdm/SVN/FCT-Editor/syntax/cbs-gen/Funcons/accumulate.sdf3 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2 [java] rewriting failed, trace: [java] editor_analyze_0_0 [java] editor_analyze_0_0 [java] report_with_failure_0_1 [java] report_failure_0_2 [java] SRTS_EXT_fatal_err_0_2
It continues like that for another 18 files, then stops reporting errors (although it takes about 2 seconds for each of the remaining approx. 100 files, most of which are very small). The project builds OK, but it is unsettling to see such “fatal” error reports.
Log in to post comments