Community
Participate
Working Groups
Build Identifier: I20110613-1736 ValidationJob is not scheduled on editor open. This can lead to certain problems not being discovered until some later point in time (in extreme case, build time). For example, if there is a cross-resource reference from 'B' to 'A' and 'A' is modified in the editor so that the reference's target no longer exists, then, when 'B' is later opened in editor, the unresolved reference will not be signalized until 'A' is saved, 'B' is modified or 'A' is further (structurally) modified. Reproducible: Always Steps to Reproduce: 1. Import the attached projects (abridged 'org.xtext.example.domainmodel') in the workspace 2. Run the runtime workbench and make a Java project with files 'A.dmodel' and 'B.dmodel' with the following contents: A.dmodel: entity A {} B.dmodel: entity B extends A {} Close the editors. 3. Open 'A.dmodel' and modify its contents to be 'entity C {}' 4. Open 'B.dmodel' and notice no error is signalized in the editor 5. Modify 'B.dmodel' without changing semantics (e.g. add some whitespace) and notice the error annotation about unresolved reference to 'A' A similar issue exists (although possibly of a different nature) when the workbench is restarted with some editors opened. In this case the editors that have not been activated will not be validated. For instance: 1. Open editors for 'A.dmodel' and 'B.dmodel'. Do not modify them. Just select the editor for 'A.dmodel' and restart the workbench 2. After restart, modify 'A.dmodel' contents (in the currently active editor) to be 'entity C {}' 3. Select the editor for 'B.dmodel' and notice no error is signalized in the editor 4. Modify 'B.dmodel' without changing semantics (e.g. add some whitespace) and notice the error annotation about unresolved reference to 'A'
Created attachment 201056 [details] Sample language projects
I've found out that the description of the second issue as given is not accurate. Steps 3 and 4 in the second issue description should be replaced with the following: "Note that the editor for 'B.dmodel' has no error tick associated with it, until it is activated". This issue is completely unrelated with the stated bug. My apologies.
Created attachment 202010 [details] Proposed patch
Hi Vladimir, thanks for the patch. Please note that we intentionally don't schedule validation jobs for each opened resource. Instead we rely on the marker to be up-to-date. The observed behavior is caused by a missing notification (#isAffected) due to bug #354910
Hi Sebastian, thanks for your reply. What I have attempted to demonstrate (but failed to describe it clearly) it that there may be no marker to rely on in case where there is a cross-resource reference (let us say from B to A) and the following sequence of events occurs. First, resource A is modified in the editor so that the cross-reference from B to A can no more be resolved. Please note that for the time being the change in A has not been saved (its editor is 'dirty') and the editor for B is not yet open. Thus no error marker is present on B and no dirty state listener for the B editor is registered. Then, when the editor for B is opened it contains no error annotation about the unresolved reference, because there is no error marker to rely on and the reconcile delta for A had been fired before the dirty state listener was registered. In this case the error annotation will only appear when either A is saved, B is modified or A is (further) structurally modified in the editor. There may be good reasons for not validating resources on open, but I just wanted to articulate that there is at least one case where it may seem necessary. Also please note that the sample language attached is not based on Xbase and hence not affected by bug 354910.
Hi Vladimir, I see, thanks for the clarification. I'll schedule a validation job if the newly opened document points to a resource, that is currently dirty.
That's a very concise formulation of what I have tried to achieve with so many words. Thanks for nailing it down, Sebastian.
Pushed to master.
Closing all bugs that were set to RESOLVED before Neon.0
