Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 356809 - Validation errors don't go away
Summary: Validation errors don't go away
Status: CLOSED WONTFIX
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-06 09:09 EDT by Aaron Digulla CLA
Modified: 2011-09-07 12:53 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Digulla CLA 2011-09-06 09:09:49 EDT
I had an error in my validation rules. After fixing the problem, installing the new editor plugin and restarting Eclipse, the error messages are still visible in the Problems view.

If I select "Validate" from the context menu on the project or an individual file, the errors don't go away. The dialog box says "Validation completed with 0 errors and 0 warnings."

When I change the file and save, the errors go away.

It seems that the Xtext editors can go out of sync with the source files.
Comment 1 Sven Efftinge CLA 2011-09-06 10:19:36 EDT
This is because within the editor the validation only produces and cleans up annotations. The persistent markers are maintained by the builder, which only runs if you have a change in the resource model (e.g. saved a dirty editor).

When opening an editor the validation is not retriggered because it's safe to rely on the persistent state from last builder run. ... well except if someone changes the language implementation. 

We could store the qualifier of the language somewhere and if that changes force a clean build, but I think a manual clean build in such a scenario works sufficiently well.
Comment 2 Aaron Digulla CLA 2011-09-07 03:06:20 EDT
Okay, the builder cache makes sense.

But why doesn't "Validate" clear the problems? It works for JSP and HTML files, for example.

I have about 300 errors in some 20 files in my problems view. Touching 20 files is annoying if a single click would suffice.
Comment 3 Sven Efftinge CLA 2011-09-07 10:24:48 EDT
I don't think opening 20 files and running the validate action for each would improve your situation. I'd suggest you do clean build.

The validate action is an editor action and is there to execute all validation checks (incl. specially marked long running ones). Those are not executed in the editor on type of safe, nor by the build. The editor itself has three validation phases
1) on type (i.e. 500ms after you stopped typing) (executes fast validations only)
2) on safe (executes fast running and normal running)
3) on "Validate" action (executes all)

None of them installs any markers on the resource. They only create non-persitent annotations in the editor.
If you wish the validate action to install markers on the resources you'll have to subclass it and extend it in that way. Maybe we should rename the validation action to avoid confusion about its purpose.
Comment 4 Aaron Digulla CLA 2011-09-07 11:43:35 EDT
(In reply to comment #3)
> I don't think opening 20 files and running the validate action for each would
> improve your situation.

I can run "Validate" on the whole project or on an individual folder, too.

> I'd suggest you do clean build.

Not perfect but I'll give it a try.

> None of them installs any markers on the resource. They only create
> non-persitent annotations in the editor.

I wasn't aware that there are two kinds of markers. I assume that the persistent markers are installed by the validation run during the build. What I don't understand is why the fast/in-editor validation can't clear the persistent markers.

As it is, this can cause all kinds of confusion and the Xtext editors are the only ones which work this way. In every other editor, in-editor and build validation are always in sync (ok, the XML editor is also buggy but that's another issue).
Comment 5 Sven Efftinge CLA 2011-09-07 12:53:46 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > I don't think opening 20 files and running the validate action for each would
> > improve your situation.
> 
> I can run "Validate" on the whole project or on an individual folder, too.
> 
I don't think Xtext's validate action is registered on any other element but an open editor.
Must be a different "Validate" action. Maybe contributed by one of the plugins you are mentioning.
As long as they don't have defined an extension point there is no was to hook into that action.

> > I'd suggest you do clean build.
> 
> Not perfect but I'll give it a try.
> 
> > None of them installs any markers on the resource. They only create
> > non-persitent annotations in the editor.
> 
> I wasn't aware that there are two kinds of markers. I assume that the
> persistent markers are installed by the validation run during the build. What I
> don't understand is why the fast/in-editor validation can't clear the
> persistent markers.

It could technically but that's not how it is meant to work.
And updating markers on resource change works nicely as a long as you don't change the validation semantics.

> 
> As it is, this can cause all kinds of confusion and the Xtext editors are the
> only ones which work this way. In every other editor, in-editor and build
> validation are always in sync (ok, the XML editor is also buggy but that's
> another issue).

No I think every proper Eclipse editor works like that. Markers are a concept on resources, annotations are a ui thingy. At least also JDT does it like Xtext.