Bugzilla – Full Text Bug Listing
| Summary: | Content assist not working correctly in a grammar using importURI | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Missing name Mising name <temp44> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cvgaviao, Holger.Schill, rahul.official, sebastian.zarnekow, sven.efftinge |
| Version: | 2.3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Missing name Mising name
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 |