Community
Participate
Working Groups
Build Identifier: 1.0.1.v201008251220 My model consists of multiple files. In each of which the CTRL Space feature stops working at an arbitrary position in the text. (different lines, different word and character counts, no error marks, no common grammar element) For some files it works again at a later position for a small part of the text. I could not find any commonalties of the location where it stops working. Normally there is nothing in the logs. But once it brought up a lot of messages like the following: org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider - Error in polymorphic dispatcher : Couldn't find method ''completeDatabase_Name'' for objects I checked that this method was generated. So what disturbed the polymorphic dispatcher? And sometimes at the end of a line CTRL Space marks the editor dirty without inserting any visible text. And sorry, I can't share the grammar or model. Regards, Marco Reproducible: Always Steps to Reproduce: 1. no idea 2. 3.
Do you use different Xtext based languages, e.g. your language files and the xtext file in the very same instance?
Hi Sebastian, The same instance of what? I have two languages in in the same set of projects, i.e. mydsls and mydsls.ui. I tried it when running as eclipse application out of the IDE, and as deployed feature in a separately installed IDE. I could not verify yet, but I think this problem is newly introduced by SR1. There is nothing customized with the ProposalProvider, and I did not recognize such issues before.
I'd assume its a wrong condition in the plugin.xml that disables / enables the proposal provider for the wrong context.
I meant the same Eclipse instance.
(In reply to comment #3) > I'd assume its a wrong condition in the plugin.xml that disables / enables the > proposal provider for the wrong context. Thx for the hint. I will check the plugin.xml. But then I could not understand why the resources of both very different languages work for until certain locations. There is one resource (>2000 lines) that works completely. It has the following specifics: - a black asterisk on its icon (don't know what it means) - no red X error mark on its icon despite there are errors marked in the resource
I found nothing suspicious in the plugin.xml. Actually I find nothing to associate with ProposalProviding at all, and in plugin.xml_gen not either.
I found out the following: The error "org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider - Error in polymorphic dispatcher : Couldn't find method ''complete_AnyDsl2Type'' for objects" just comes up when editing resources of Dsl2. For types of Dsl2 which have the same name as a type of Dsl1 the completeType methode of AbstractDsl1ProposalProvider is called. So obviously the ProposalProvider of Dsl1 is use for Dsl2. But keywords of Dsl2 are proposed correctly, at least in the beginning area of a Dsl2 resource. I change Dsl2 to have only objects with names different from names in Dsl1 (except Terminals). But it did not change the erroneous behavior described before: Dsl2 resolves keywords at the beginning of resources, and reports the polymorphic dispatcher error for the rest. Dsl1 does not report any errors, but works only at the beginning of resources. I guess that there are 2 issues: 1. reference of wrong ProposalProvider for projects with multiple languages 2. ProposalProvider gets somehow lost in parsed tree and tries to propose for the wrong nodes.
We have to move the handler registration from xtext.ui to mylang.ui and use a predicate for the active language. I don't see a way to backport this one to Helios, though.
What does this mean: 1. I need to avoid conflicting type names for languages in same project? 2. Is this also true for Terminals which would mean that I could not even use the default evaluators for e.g. ID and STRING? 3. ProposalProviders are unusable for multiple languages in same project? If 3, are you sure that the issue is fixed if I go the full effort to separate the languages in different projects? /m
I separated the languages in different project set. This did not help. By debugging I found out for a language similar to Type1 : name = ID attr = [Type2] 1) For the first 2 instances of Type1 in the resource the proposal for attr are just fine listing all instances of Type2 by calling completeType1_Attr. 2) For the 3rd instance of Type1 suddenly a complete unrelated methode is called: completeType3_Name. It seems that ProposalProvider goes abstrait in the parsed tree. The problem seems to be some here in createProposal: for (AbstractElement element : context.getFirstSetGrammarElements()) { selector.accept(element); In the correct cases (the first 2 instances firstSetGrammarElements just consists of the correct element (the assignment of attr). For the 3rd instance firstSetGrammarElements is filled up with a punch of unrelated grammar elements. The context has the correct lastCompleteNode and the correct currentNode. But element then still as something completely different. (the mentioned assignment of name) Type1 has a much more complicated syntax with an embedded expression. But the parser works fine when e.g. checking syntax, reporting errors, and highlights keywords. Hope this helps to find the bug.
Actually I think the problem is somewhere here in createContexts: currentNode = getContainingDatatypeRuleNode(currentNode); for (Entry<EObject, Collection<AbstractElement>> entry : contextMap.asMap().entrySet()) { ContentAssistContext context = createContext(viewer, completionOffset, parseResult, rootNode, lastCompleteNode, entry.getKey(), currentNode, prefix); for(AbstractElement element: entry.getValue()) { context.accept(element); } Because currentNode is still right, but the contexts build for it are wrong.
Excerpt from the mwe2: fragment = contentAssist.JavaBasedContentAssistFragment {} ragment = ContentAssistParserGeneratorFragment { options = { backtrack = true ignoreCase = true classSplitting = true } }
*** Bug 328442 has been marked as a duplicate of this bug. ***
See comment #8 : We know what the bug is but we don't see a way to fix this in a service release. Sorry. (In reply to comment #8) > We have to move the handler registration from xtext.ui to mylang.ui and use a > predicate for the active language. I don't see a way to backport this one to > Helios, though.
Thx for the answer. When will there be a release of a fixed version which is mature enough for production? I can probably not effort to wait till then. What can I do to work around it, even with limitations? /m
Sebastian, I am shocked by your further delaying the resolution of this bug. At least for me it prevents any reasonable usage. I urgently need at least a work-around. If this is not a common issue, what triggers it's appearance? Maybe I can do something in my application to avoid it for the moment. Thanks, Marco
I have a similar problem. In my case, content assist works perfectly for a while. And then it stops working with the following error: org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider - Error in polymorphic dispatcher: null If I close the file, and open it again. It starts to work all over again.
Scheduled for M5. We know what to do about this one. Unfortunately I see nothing that we can do for Xtext 1.0.1 and 1.0.2. Clients could try to recompile Xtext and modify the plugin.xml of the xtext.ui plugin. However, it would break binary compatibility if we did this generally.
Can you show me what I need to modify in plugin.xml 's to get this to work consistently?
Marco, Samantha, would it be possible to provide a small sample project which helps to reproduce the issue?
Defered since I cannot reproduce the issue. Please provide a self contained example with some steps to reproduce the problem.
Sebastian, Unfortunately I cannot provide my project because model and even grammar includes intellectual property of somebody else. I can just use it. But no way to publish it. Sorry. But what changed? You said: >>> Scheduled for M5. We know what to do about this one. Unfortunately I see nothing that we can do for Xtext 1.0.1 and 1.0.2. <<< How else can I help to find the issue? Do you have any idea what attributes a project must have to have this issue? Please do not give up. Currently it looks like there is the risk that any project can hit an unknown limitation making all the effort void. Thanks, Marco
Created attachment 237060 [details] Xtextproject with an xtext-dsl-file which causes the: Error in polymorphic dispatcher
Hello, a detailed explanation of the problem may be found in the forum: http://www.eclipse.org/forums/index.php/t/573876/ It would be great if someone may introduce a workaround for this problem. Regards, Alex
Xtext unsets cross-references after reparsing. It doetreats every EReference 'ref' with the following state as a cross reference: !ref.isContainment() && !ref.isContainer() && !ref.isDerived() && ref.isChangeable() && !ref.isTransient() The UML ecore defines EReferences which pass this guard, and when clearing them they remove elements from containments. In this case it the elements in 'ownedEnd' are removed when clearing 'memberEnd'. We cannot fix that in general, as it stems from UML madness ;-) But a fix for you would be to subclass the LazyLinker and override clearReference. Where you explicitly check which references you want to clear. Something like this would work for the given grammar : public class UmlLazyLinker extends LazyLinker { @Override protected void clearReference(EObject obj, EReference ref) { if (ref == UMLPackage.Literals.TYPED_ELEMENT__TYPE) super.clearReference(obj, ref); } } You bind that new class by going to the RuntimeModule and add : @Override public Class<? extends ILinker> bindILinker() { return org.xtext.example.bug.UmlLazyLinker.class; }
Requested via bug 522520. -M.
