I have a strange issue with SDF3-symbolsorts. It seems to retain some old and now invalid paths, causing the analysis of some SDF3 files to fail. For example, in one project I have a file that starts like this:

module WebDSL-Lexical

lexical syntax

	ID									= [a-zA-Z][a-zA-Z0-9\_]*
	QID									= {ID "."}+

// ...more

And I get these errors on analysis/saving:

Internal error evaluating editor-analyze (InterpreterException; see error log)
rewriting failed, trace:
	editor_analyze_0_0
	analysis_default_editor_0_0
	analysis_single_default_interface_0_0
	analysis_single_default_3_1
	analysis_single_default_4_1
	analysis_files_spoofax_4_2
	analysis_files_spoofax_5_2
	analysis_spoofax_output_1_0
	report_with_failure_0_1
	report_failure_0_2
	SRTS_EXT_fatal_err_0_2
	
org.spoofax.interpreter.core.InterpreterException: Exception during evaluation
Caused by: org.spoofax.interpreter.core.InterpreterErrorExit: Internal error: with clause failed unexpectedly
	in 'analysis-spoofax-output'
	
Invalid resource path is provided :
	"D:\Opleiding\2013-2014\Afstuderen\Workspaces\WebDSLEditor2\WebDSL\expressions\syntax\WebDSL-References.sdf3"
java.io.FileNotFoundException: File not in workspace:
	D:\Opleiding\2013-2014\Afstuderen\Workspaces\WebDSLEditor2\WebDSL\expressions\syntax\WebDSL-References.sdf3

The path displayed in the error is an old path that is no longer valid. I once had to move the project to a different directory.

Note that WebDSL-References.sdf3 is not imported in the problematic file. Strangely enough, compilation suddenly succeeds if I change the module name to something else.

module WebDSL-Lexicalxxxxxx

lexical syntax

	ID									= [a-zA-Z][a-zA-Z0-9\_]*
	QID									= {ID "."}+

// ...more

If I change it back, compilation fails again. Cleaning the project and deleting the src-gen directory doesn’t help, neither does restarting Eclipse.

---

To reproduce:

1. Take a project with valid SDF3 files.
2. Build it.
3. Copy the project directory somewhere else.
4. Import the copied project in a (new) workspace.
5. Try building the copy.

Now the errors pop up.

---

I found a workaround:

1. Clean the project. (Don’t (re)build!)
2. Restart Eclipse.

Submitted by D. Pelsmaeker on 21 July 2014 at 13:24

I think I know what is happening here. The SDF3 compilation requires knowledge about all SDF3 files in the project. Normally the information is available, when you open the project for the first time it will analyze all SDF3 files, and then incrementally analyze changes. However, when you move the project (including the .cache folder), all data in the index will be useless because we use absolute paths in the index. Because there is already a .cache/index.idx file, it will not re-analyze the entire project. Then the SDF3 compilation fails, because information is missing. Eclipse normally detects renames/moves of files, even when the IDE is not open, but probably not if you move the entire project to a different workspace or instance of Eclipse.

Cleaning the project and restarting fixes the issue because the .cache directory is deleted, and restarting will also remove the index from memory. Another workaround is to do a reset & reanalyze in the project with SDF3 files.

To fix this issue, we would need to do consistency checks our self, to check if files do or do not exist in the project, instead of relying on Eclipse. I may be able to work on this while refactoring Spoofax here at Oracle.

I can confirm that remnants of the old paths can be found in files in the .cache directory, so you’re probably right.

However, in theory if I would copy a project instead of moving it, and the index still refers to the files that exist at their old locations, then I would get all sorts of weird inconsistencies. So it’s not just a matter of whether the files exist. Since Eclipse can track renames of files within a project, perhaps it would be sufficient to check as to whether just the project (root) is still in its expected directory. If it’s not, reset the index.

Yes you are right, I meant checking if the file exists inside the project. Just checking the root directory would be sufficient, but I rather not completely rely on Eclipse file system notifications, since they go wrong sometimes. Making the paths in the index relative, and doing consistency checks at certain points will make it more resilient and portable outside of Eclipse.

[deleted]

Did you delete your last comment or does it not render?

There is no delete button, so I removed the content. My statement was incorrect and therefore no longer relevant.