Epoch error reporting

[edwardalee]

This fixes #966 . It modifies MANIFEST.MF, which makes me nervous.

[lhstrh]

I'm surprised to see that it has been reporting errors on the path (not the file). I think @petervdonovan should review. Adding the dependency is fine, but we should use the right version (see suggestion).

[petervdonovan]

I'm surprised to see that it has been reporting error on the path (not the file).

It looks like this change happened during refactoring only 2 weeks ago (commit b57c402), so maybe it is not that surprising that the problem was only found recently.

What I do find strange is that, directory/file confusion aside, I am not sure that the idea behind the change introduced in b57c402 was correct. Before b57c402, we reported errors on the resource that had just been validated. Now, the error is reported on the root file of the code generation process.

[lhstrh]

I'm surprised to see that it has been reporting error on the path (not the file).

It looks like this change happened during refactoring only 2 weeks ago (commit b57c402), so maybe it is not that surprising that the problem was only found recently.

What I do find strange is that, directory/file confusion aside, I am not sure that the idea behind the change introduced in b57c402 was correct. Before b57c402, we reported errors on the resource that had just been validated. Now, the error is reported on the root file of the code generation process.

Ah, you're right -- very good detective work! I recall b57c402. Looks like we should just revert the changes on line 231. We should probably answer the FIXME that was in that code, however. If the code is correct, we should probably put it in a static method of FileConfig for convenient reuse.

[edwardalee]

I'm surprised to see that it has been reporting errors on the path (not the file). I think @petervdonovan should review. Adding the dependency is fine, but we should use the right version (see suggestion).

I committed your suggestion, and it cause CI to fail with this error:

Error:  Cannot resolve project dependencies:
[97](https://github.com/lf-lang/lingua-franca/runs/5218982626?check_suite_focus=true#step:8:97)
Error:    Software being installed: org.lflang 0.1.0.qualifier
[98](https://github.com/lf-lang/lingua-franca/runs/5218982626?check_suite_focus=true#step:8:98)
Error:    Missing requirement: org.lflang 0.1.0.qualifier requires 'osgi.bundle; org.eclipse.core.runtime 3.24.0' but it could not be found
[99](https://github.com/lf-lang/lingua-franca/runs/5218982626?check_suite_focus=true#step:8:99)

So we should revert this commit.

[lhstrh]

Let me downgrade the dependency in Gradle/Maven and see if that works...

[lhstrh]

Looks good to me, but I haven't had a chance to check it with Epoch, so please check with the latest changes before merging.

[lhstrh]

@a-sr: this PR is now in a state where there is a remaining problem that we don't seem able to fix.

If an error marker is added through validation triggered by the Compile button, then the marker will not be removed if the error is fixed (even if the document is saved) until the Compile action is invoked again. It appears that validator instances only remove markers that they have added, leaving markers added by others untouched. I attempted removing the markers explicitly in LFValidator.checkModel() but the available eResource is apparently not an iResource and can therefore not be cast to an iFile (which has the deleteMarkers() method). Any help with this would be greatly appreciated!

[cmnrd]

The EclipseErrorReporter has a method clearMarkers which should clear all the error markers.

As far as I know, this method is called in doGenerate of GeneratorBase. Probably it should be called instead by some hook that is invoked on file save.