The call-onsave often fails when building a project for the first time (after starting up Eclipse).
It also fails after generating a new entity language project, such that you need to build the project twice.
It seems to be some problem with the analysis.

call-onsave:
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/BuiltInCalls.sdf3
	[java] rewriting failed, trace:
	[java] 	editor_analyze_0_0
	[java] 	editor_analyze_0_0
	[java] 	analysis_default_editor_0_0
	[java] 	analysis_single_default_interface_0_0
	[java] 	analysis_single_default_3_1
	[java] 	analysis_single_default_4_1
	[java] 	analysis_files_spoofax_4_2
	[java] 	analysis_files_spoofax_5_2
	[java] 	analysis_spoofax_output_1_0
	[java] 	map_1_0
	[java] 	analysis_spoofax_update_file_1_0
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Common.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Expressions.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/GMQL.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Keywords.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Lexical.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/SelectClause.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/trans/names.nab
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/trans/types.ts

Submitted by Oskar van Rest on 8 August 2014 at 00:33

It’s not always the first SDF3 file that fails:

call-onsave:
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/syntax/Asdf.sdf3
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/syntax/Common.sdf3
	[java] rewriting failed, trace:
	[java] 	editor_analyze_0_0
	[java] 	editor_analyze_0_0
	[java] 	analysis_default_editor_0_0
	[java] 	analysis_single_default_interface_0_0
	[java] 	analysis_single_default_3_1
	[java] 	analysis_single_default_4_1
	[java] 	analysis_files_spoofax_4_2
	[java] 	analysis_files_spoofax_5_2
	[java] 	analysis_spoofax_output_1_0
	[java] 	map_1_0
	[java] 	analysis_spoofax_update_file_1_0
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/trans/names.nab

Can’t seem to reproduce this on OSX with same Spoofax and same Eclipse version as Oskar. He runs Linux so it may be a Linux issue. We’re trying on Windows as well.

I’ve tried to reproduce with a Windows and Ubuntu VM, on both Eclipse Kepler and Luna, but could not do it. This only seems to happen on Oskar’s machines :S

Does the on-save handler work after the first build? Isn’t it because the analysed asts are not ready (failing to generate the signatures)?

On the first build when calling the on-save handler, it will set up the index, which triggers analysis for all SDF3 files because an index does not exist yet. Full analysis is then triggered on a background thread, blocking all other Stratego analysis jobs (such as the on-save handler). However, it might be possible that the full analysis in the background thread gets priority later than the first on-save call, which will then fail. Sounds like it might be a race condition, which somehow does not happen on my laptop.

With the latest nightly, I don’t have this problem anymore. Tried it with both my Linux and Windows machine.

Closing the issue.

Somehow got the error again after generating a new language:

call-onsave:
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/syntax/Abc.sdf3
    [java] generating for Abc.sdf3
    [java] Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.
    [java] rewriting failed, trace:
    [java] 	editor_save_0_0
    [java] 	generate_all_0_0
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/syntax/Common.sdf3
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/trans/names.nab

Does it work after the first build?

I get the same problem on my Macbook Air:
OSX 10.10.1
Eclipse Luna 4.4.1
Spoofax 1.3.1

I’m trying to set up a live coding demo for Spoofax, so I create a new minimal project and 2 example files:

exampleSchema.sql:

CREATE TABLE EMP (
  empno NUMBER(5),
  ename VARCHAR(255)
);

example.sql:

SELECT e.ename
FROM EMP e
WHERE e.empno = e.ename
;

Then I define a simple grammar for the example schema:

Start.SQL = <{Query "\n\n"}+>
Query.TableDef = <
  CREATE TABLE <ID> (
    <{ColDef ",\n"}+>
  );
>
ColDef.ColDef = <<ID> <DataType>>
DataType.Num = <NUMBER(<INT>)>
DataType.Str = <VARCHAR(<INT>)>

When I build, exampleSchema.sql has syntax highlighting.

So then I move on to the Select query:

Query.Select = <
  SELECT <{ColRef ", "}+>
  FROM <{Fro ", "}+>
  <WhereClause?>
>
ColRef.ColRef = <<ID>.<ID>>
Fro.Fro = <<ID> <ID>>
WhereClause.Where = <WHERE <Predicate>>
Predicate.Equals = <<Operand> = <Operand>>
Operand.Col = <<ColRef>>

But then, when I save, the sdf file does not get regenerated.
And when I build I get the same message that Oskar got:
Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.

@Eduardo, to answer your earlier question: it also happens after the first build, at least in the case it also failed during the first build. I’m not sure if it also happens if the first build was successful.

Also, it happens for SDF3 files that are opened in the editor, even though they must have been analyzed.

I still think this is a race condition, which means it will be triggered pretty randomly. One way we could solve this in the current architecture, is to trigger analysis for all SDF3 files, and then call the on-save handlers, but this would mean all files are parsed and collected twice.

@Volker : I checked your example, and except for a typo in:

Start.SQL = <{Query "\n\n"}+>

that is missing surrounding <>, therefore producing a syntax error in the grammar, the SDF2->SDF3 transformation of these two grammars works fine in Spoofax 1.3.1.
If it happens all the time, there might be an error in the transformation rules, if not, it might be because of the analysis issue that Gabriël described before.

It seems to be an analysis bug.
When there is a template referring to the same sort twice, renaming this sort will trigger the bug.

This is 100% reproducible on my system, but just in case it is one of those “it works on my machine”-bugs, I created a screen capture of the problem:
http://youtu.be/JKfWDLGgmIs

Yes, I don’t think it is an SDF bug indeed. If you do reset and reanalyze after it fails, does it work?
@Gabriël: Do you still think it is the race condition you described before?

The problem is that there is no Analysis menu and so no “reset and reanalyze” available in the SDF3 file. So I wouldn’t know how to test that.
Changing and saving the SDF3 file does not fix the issue.

There is a new context menu on projects called Spoofax, which allows you to reload the analysis data.

Reloading analysis data and saving the file makes it work.
However, if I rename the sort again, the problem arises again.
I guess that verifies that it is Analysis related.

Well having to “reset and reanalyze” manually is a real issue. It prevented the people in Oxford of building languages that contain SDF3.
The behaviour we had there was basically every first git checkout the build would fail because SDF3 files had analysis errors. After the first build it didn’t occur anymore.
Especially because the clean checkout didn’t work but the second build working fine was confusing.

@Eduardo, Guido: Is the analysis on SDF3 failing (in some instances, with correct code, and having to reset and reanalyze) an SDF3 bug or a NaBL/TS bug?