Skip to main content


Eclipse Community Forums

      Home
Home » Modeling » TMF (Xtext) » Bug in commons.types???(getQualifiedName in JvmIdentifiableElementImpl)
Bug in commons.types??? [message #1061448] Fri, 31 May 2013 12:11 Go to next message
Eclipse UserFriend
Hi,

I am wondering if the following is a bug or I'm using it in the wrong way?

In my grammar I have a rule that returns a JvmTypeParameter (setting name with an ID), and I get the following error when in the editor:

java.lang.UnsupportedOperationException
	at org.eclipse.xtext.common.types.impl.JvmIdentifiableElementImpl.getQualifiedName(JvmIdentifiableElementImpl.java:94)
	at org.eclipse.xtext.common.types.impl.JvmIdentifiableElementImplCustom.getQualifiedName(JvmIdentifiableElementImplCustom.java:17)
	at org.eclipse.xtext.xbase.scoping.XbaseQualifiedNameProvider.getFullyQualifiedName(XbaseQualifiedNameProvider.java:34)
	at org.eclipse.xtext.naming.IQualifiedNameProvider$AbstractImpl.apply(IQualifiedNameProvider.java:31)
	at org.eclipse.xtext.naming.IQualifiedNameProvider$AbstractImpl.apply(IQualifiedNameProvider.java:1)
	at org.eclipse.xtext.scoping.Scopes$2.apply(Scopes.java:91)
	at org.eclipse.xtext.scoping.Scopes$2.apply(Scopes.java:1)
	at com.google.common.collect.Iterators$8.next(Iterators.java:782)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:644)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
	at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.setExportedObjects(MultimapBasedSelectable.java:97)
	at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.<init>(MultimapBasedSelectable.java:36)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider.internalGetAllDescriptions(XbaseImportedNamespaceScopeProvider.java:267)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider$3.get(XbaseImportedNamespaceScopeProvider.java:255)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider$3.get(XbaseImportedNamespaceScopeProvider.java:1)
	at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:75)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider.getAllDescriptions(XbaseImportedNamespaceScopeProvider.java:253)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider.getGlobalScope(XbaseImportedNamespaceScopeProvider.java:82)
	at org.eclipse.xtext.xbase.scoping.XbaseImportedNamespaceScopeProvider.getScope(XbaseImportedNamespaceScopeProvider.java:75)
	at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.delegateGetScope(XbaseBatchScopeProvider.java:57)
	at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.getScope(XbaseBatchScopeProvider.java:79)
	at org.eclipse.xtext.xbase.annotations.typesystem.XbaseWithAnnotationsBatchScopeProvider.getScope(XbaseWithAnnotationsBatchScopeProvider.java:50)
	at fr.irit.smac.may.juno.spead.scoping.SpeADLBatchScopeProvider.getScope(SpeADLBatchScopeProvider.java:18)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getScope(DefaultLinkingService.java:61)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:123)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:198)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:99)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReference(LazyLinkingResource.java:155)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReferences(LazyLinkingResource.java:114)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:144)
	at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:510)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(ResourceValidatorImpl.java:154)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:67)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:79)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:1)
	at org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.readOnly(AbstractReadWriteAcces.java:32)
	at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.readOnly(XtextDocument.java:218)
	at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:79)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(ValidationJob.java:75)
	at org.eclipse.xtext.ui.editor.validation.ValidationJob.run(ValidationJob.java:64)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


The code can be looked at:
https://wwwsecu.irit.fr/hg/SMAC/victor-noel-phd/may/may-xtext2-kevin

Thanks
Re: Bug in commons.types??? [message #1061451 is a reply to message #1061448] Fri, 31 May 2013 12:48 Go to previous message
Eclipse UserFriend
I think this is actually the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=402669

My rule TypeParameter retuns a JvmTypeParameter, and thus its implementation extends JvmTypeParameterImpl instead of JvmTypeParameterCustomImpl which implements the getQualifiedName(String arg).

[Updated on: Fri, 31 May 2013 12:49] by Moderator

Previous Topic:Editing the description of an attribute
Next Topic:Nested comments
Goto Forum:
  


Current Time: Sat Jul 26 07:12:32 EDT 2025

Powered by FUDForum. Page generated in 0.04118 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly