Community
Participate
Working Groups
Build Identifier: M20110210-1200, I20110613-1736 Happens in Xtext 1.0.2 and 2.0.0 We have 2 DSL files A and B, where B imports A. If we have an object in file B which cross references objects specified in A, firing content assist in B should display all relevant objects in A. If we however add a new object to A while the editor for B is open, and fire content assist in B, the list does not show the newly specified object. After closing and reopening the editor for B, the content assist list shows correctly. For details on the test case in "Steps to Reproduce", see http://www.eclipse.org/forums/index.php/t/216149/ Reproducible: Always Steps to Reproduce: 1. Create a new Xtext project 2. Modify mwe2 generator to make use of the importURI feature 3. Add an object with importURI feature to the grammar ("Import: 'import' importURI=STRING;") 4. Add an object cross-referencing another object (by default, the Greeting object) to the grammar ("RefGreeting : 'ref' grtng=[Greeting];") 5. Generate the language, launch as Eclipse application 6. Create a new project with the following two DSL files: 7. In file A.mydsl define two Greeting objects ("Hello world!", "Hello space!") 8. In file B.mydsl add an import of A.mydsl via importURI ("import 'A.mydsl'") 9. In file B.mydsl add a reference to the "world" greeting ("ref world"), save the file, do not close the editor 10. Open the A.mydsl editor, define another Greeting object ("Hello school!"), save the file 11. Tab back to the B.mydsl editor and fire content assist on the "ref" definition - the "school" Greeting object defined in step 10 does not show up in the list (this is the bug) 12. After closing and reopening the B.mydsl editor, fire content assist on the "ref" definition - the "school" Greeting object defined in step 10 is now in the list
Bumping this, as the issue prevails already since version 1.0.0 up to 2.2.0. Can anyone please take a look at this?
Hi, can anyone of the devs please comment on this issue, at least give a statement that they are tracking it, and when it might be addressed? It has been almost a year now, and it still exists even in Xtext version 2.3.0. I tried to do some debugging lately, but I have too little knowledge of Eclipse internals to come up with anything useful. Thanks a lot.
Thanks for the reminder. You may want to debug DirtyStateEditorSupport.isReparseRequired(XtextResource, Event) which should probably use the normalized version of the resource's URIs to decide about reparse / not reparse. Preliminary scheduled for 2.3.x. If it turns out to have too much impact, it's unlikely to change before 2.4.
Hi, thanks for the statement. I tried to put a breakpoint there, but it never gets even called. The problem seems to be that the A resource is not updated when it is modified. Well, actually *some* resource is reloaded (recreated). But when triggering content assist, LoadOnDemandResourceDescriptions.getResourceDescription(URI) is called, which in turn calls EcoreUtil2.getResource, but the returned resource somehow contains the previous state of the model. I stopped there in XtextResourceSet.getResource(URI, boolean) and before evaluating "loadOnDemand && !resource.isLoaded()" i set resource.isLoaded to false. After that, the resource was updated and content assist worked correctly. So it actually seems to be a problem with the builder, which appears not to reload all existing resource instances for a specific URI, but rather only some of them (or recreate a new one...). Also, the resource description of A which gets cached upon build is different than the resource description fetched by LoadOnDemandResourceDescriptions during content assist (it is fetched from the same cache instance, but the resource has a different eAdapter than the resource during the build, dont know if that is relevant). I dont really understand how all of this works, but these are my observations. If you could point me where to look further, I can play with it a little more. Right now I dont really know where to look. Thanks
Hi, please put a breakpoint into DirtyStateEditorSupport.modelChanged(XtextResource) before you perform step 10. Open the A.mydsl editor, define another Greeting object ("Hello school!"), save the file (I'd recommend to paste 'Hello school!' since that'll reduce the number of events that are thrown You should hit the breakpoint and the change *should* be propagated to announceDirtyStateChanged(..) which in turn *should* hit DirtyStateEditorSupport.descriptionsChanged(Event) of editor B.mydsl Last but not least you'll end up in DirtyStateEditorSupport.UpdateEditorStateJob.run(IProgressMonitor) which should finally do a resource.reparse(document.get()); of resource B. Please let me know where this assumption does not hold.
Well, I feel a little embarrassed right now, as I probably figured out what the problem was. However, I would like to make sure, meaning I need some more time to work with my DSL to confirm the problem is completely gone. I did what you suggested and tried it out on my DSL. However, I never ever hit event the first breakpoint you described. So I tried to recreate the test case from scratch. Suddenly, everything worked. After looking into it a little more, I noticed that in my DSL mwe2 generator, I had commented out "fragment = builder.BuilderIntegrationFragment {}" (as I described in the forum post mentioned). After I enabled the fragment, I hit the breakpoint you described, so I decided not to debug further and tested it out. From the little testing it seems to work perfectly. However, I'd like some time to work a little more with my DSL editor to be sure the issue is completely gone. What is the process regarding the bug report in this case, can the bug remain open for some longer time, or should it be closed and reopened if needed? Anyway, thanks a lot for your help, I would never be able to figure this out on my own. Oh, and of course thanks for Xtext itself, it is a great tool... ;-) Kind regards
Thanks for coming back to this one and the nice words. I'll leave this one open until someone verified that we don't have to use normalized URIs according to comment #3.
I was also facing the same problem. In my case also I had commented "fragment = builder.BuilderIntegrationFragment {}". After uncommenting this everything is working now. Thank you very much for the help.
I think we could mark this one as fixed since the org.eclipse.xtext.scoping.impl.ImportUriGlobalScopeProvider relies on the index and therefore the BuilderIntegrationFragment is needed.
Hi, I have not had any issues regarding this for a month, it seems to work perfectly. So on my behalf, this can be closed. However, Sebastian wanted to look into it a little further according to comment #7, so I'll leave it up to him to decide whether to close this. Kind regards
see comment 7
