Old generated signatures persist even after source file is deleted/renamed

[molenzwiebel]

Summary

Generated signature files persist in the build folder even after the file they originated from has been removed/deleted. Files that import these signatures will continue to type check, even though a fresh build (after removing the build folder) will cause issues.

What you did

1. Create some foo.sdf3 that contains declarations.
2. Import signatures/foo-sig in Statix.
3. Rename foo.sdf3 to bar.sdf3.
4. Build successfully.
5. Observe that the import in Statix is still valid because the file still exists.
6. Clean the project through Eclipse.
7. Build successfully.
8. Observe that the import in Statix is still valid because even cleaning does not delete unused files in the build folder.

What you expected to happen

Preferably: errors immediately. Acceptable: errors after cleaning the project through Eclipse.

What actually happened

Only deleting the build folder causes the import to fail.

Context

• Spoofax version: devenv with spoofax-pie 389964a5

[Gohla]

Good catch! Currently we do not delete provided files of tasks that become unobserved and are deleted, as a safety measure to not accidentally delete important files. Maybe we can start deleting files that are in the ./build directory, as these are always generated and safe to delete. That would at least show errors after the build completes.

To get errors immediately on rename, we need to get rid of including directories with generated files, and instead directly depend on the tasks that generate those files, with those tasks returning the list of files they've generated. Then, when an SDF3 file is renamed, the old generated signatures are not provided any more, the generator task does not return those files any more, and the import would fail immediately.

Unfortunately, this is not possible with Statix as Statix only supports directory includes at the moment. Statix would have to be changed to support this, which is nontrivial because includes are handled through Stratego primitives during which we do not have access to the PIE context. A similar problem exists for Stratego, but that is probably easier to fix due to the include logic being executed as part of PIE tasks.