Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » [Xbase] getting the result type of an expression during inferring
[Xbase] getting the result type of an expression during inferring [message #1130093] Wed, 09 October 2013 08:19 Go to next message
Nicolas Cabanis is currently offline Nicolas CabanisFriend
Messages: 15
Registered: July 2009
Junior Member
Hello!

I am writing a GUI-Description-Language and I am using Xbase. I need to find the result type of an xbase expression during inferring.

Excerpt from the Grammar:
   WidgetProperty:
      propertyDefinition=[tkdef::WidgetPropertyDefinition]
      ( '=' '{' (expressionValue = XExpression)? '}' )?
      ( 'renderWith' renderWith = [Widget|QualifiedName] )?
      ( '{' (nestedProperties += WidgetProperty ','?)* '}' )?
   ;


A complex usage example for this.
   widget Table ResultTable {
      Content = {Partners} {
         Column { Title = {"Name"}    Value = { Name } }
         Column { Title = {"Vorname"} Value = { if (it instanceof NatPerson) "irgendwas" else "anderes" } }
      }
   }


Data-Model:
   public class RootModel {
      public List<Partner> getPartners () { ... }
   }
   public class Partner {
      public String getName () { ... }
   }


The nested properties should get a more specific data context from the parent properties if they define a data-binding expression (like "Partners" in this case). The result type of that expression is supposed to be the data-context for the nested properties.

Simplified Inferrer:
   def dispatch void infer (GuiDescription element, IJvmDeclaredTypeAcceptor acceptor, boolean isPreIndexingPhase)
   {
      acceptor.accept (element.toClass (name))
      .initializeLater[
         element.eAllContents.filter (WidgetProperty).forEach [widgetProperty, counter|
            val returnType = ...
            members += element.toMethod ('''eval_XbaseExpression_«counter»''', returnType) [
               parameters += element.toParameter ("it", widgetProperty.parameterType)
               body = widgetProperty.expressionValue
            ]
         ]
      ]
   }

   def JvmTypeReference getParameterType (WidgetProperty property)
   {
      if (property.eContainer instanceof WidgetProperty) {
         val parentProp = property.eContainer as WidgetProperty
         if (parentProp.expressionValue != null) {
            return parentProp.expressionValue.inferredType
         } else {
            return parentProp.parameterType
         }
      }
      return property.widget.dataModel.newTypeRef
   }


The problem is now that expressionValue.inferredType does not work (and the docu says: don't use it). But what else to use? Is it at all possible to get the resulting type of the expression?

The exception that raises if used:
Caused by: java.lang.UnsupportedOperationException: TODO: import a functional handle on the type resolution that delegates to the best available (current, but evolving) result
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:141)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultBatchTypeResolver$1.reentrantResolve(DefaultBatchTypeResolver.java:122)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.delegate(CachingBatchTypeResolver.java:114)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:61)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:1)
	at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36)
	at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:127)
	... 91 more


Regards
Nicolas Cabanis

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1132598 is a reply to message #1130093] Fri, 11 October 2013 08:56 Go to previous messageGo to next message
Nicolas Cabanis is currently offline Nicolas CabanisFriend
Messages: 15
Registered: July 2009
Junior Member
 
   var typeRef = expression.inferredType
   expression.eResource.contents.add (typeRef)
   typeRef.type  // resolve

It works if the XComputedTypeReference (typeRef) is added to the Resource of the XExpression. Probably I am not supposed to do that.

Is there no clean way of resolving the result type of an expression during inferring?

[Updated on: Fri, 11 October 2013 08:57]

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1132609 is a reply to message #1132598] Fri, 11 October 2013 09:07 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
did you have a look at the domain model example.
As far as I remember there the return type for methods is optional
(and thus inferrerd from the body expression)

--
Need training, onsite consulting or any other kind of help for Xtext?
Go visit http://xtext.itemis.com or send a mail to xtext at itemis dot de

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178440 is a reply to message #1132609] Sat, 09 November 2013 17:07 Go to previous messageGo to next message
Miguel Carboni is currently offline Miguel CarboniFriend
Messages: 8
Registered: September 2013
Junior Member
Hi, I'm experiencing a similar issue.

I have a grammar for defining objects with it properties and messages (those are features), then it gets into java through the jvm model inferrer.

When the property type is declared explicitly everything seems right. When it should be inferred by the initialization value it breaks.

Grammar:
...
Feature:
 Property | Message;
 
Property:
  name=ValidID (':' type=JvmTypeReference)? ('startsWith' value=XExpression)?;
...


The Inferrer includes:
...
	def dispatch void infer(HoopeObject element, IJvmDeclaredTypeAcceptor acceptor, boolean isPrelinkingPhase) {

...

		acceptor.accept(jvmGenericType).initializeLater [
			documentation = element.documentation
			for (feature : element.features) {
				switch feature {
					Property: {
						val type = feature.type?: feature.value.inferredType
						
						members += feature.toField(feature.name, type) [
							initializer = feature.value
						]
						members += feature.toGetter(feature.name, type)
						members += feature.toSetter(feature.name, type)
					}
...
}


This works perfectly...
val pepita = object {
	energia : double startsWith 2.0
...
}


but when I try to let the inferrer infer the type of Property initial value:
val pepita = object {
	energia startsWith 2.0
...
}


Bang!

WrappedException: java.lang.UnsupportedOperationException: TODO:
import a functional handle on the type resolution that delegates
to the best available (current, but evolving) result (see logs
for details)

This gets to console:
!STACK 0
java.lang.UnsupportedOperationException: TODO: import a functional handle on the type resolution that delegates to the best available (current, but evolving) result
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:141)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultBatchTypeResolver$1.reentrantResolve(DefaultBatchTypeResolver.java:122)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getDelegate(CompoundReentrantTypeResolver.java:79)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getDelegate(CompoundReentrantTypeResolver.java:114)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getActualType(CompoundReentrantTypeResolver.java:106)
	at org.eclipse.xtext.xbase.typesystem.internal.ForwardingResolvedTypes.getActualType(ForwardingResolvedTypes.java:39)
	at org.eclipse.xtext.xbase.typesystem.InferredTypeIndicator.getTypeReference(InferredTypeIndicator.java:78)
	at org.eclipse.xtext.xtype.impl.XComputedTypeReferenceImplCustom.getEquivalent(XComputedTypeReferenceImplCustom.java:46)
	at org.eclipse.xtext.common.types.impl.JvmSpecializedTypeReferenceImplCustom.getType(JvmSpecializedTypeReferenceImplCustom.java:23)
	at org.eclipse.xtext.xbase.scoping.batch.BucketedEObjectDescription.computeShadowingKey(BucketedEObjectDescription.java:79)
	at org.eclipse.xtext.xbase.scoping.batch.BucketedEObjectDescription.getShadowingKey(BucketedEObjectDescription.java:62)
	at org.eclipse.xtext.xbase.scoping.batch.AbstractSessionBasedScope.getShadowingKey(AbstractSessionBasedScope.java:169)
	at org.eclipse.xtext.xbase.scoping.batch.AbstractSessionBasedScope.isShadowed(AbstractSessionBasedScope.java:179)
	at org.eclipse.xtext.scoping.impl.AbstractScope$ParentIterable.apply(AbstractScope.java:67)
	at org.eclipse.xtext.scoping.impl.AbstractScope$ParentIterable.apply(AbstractScope.java:1)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
	at com.google.common.collect.Iterators$5.hasNext(Iterators.java:539)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.getLinkingCandidates(AbstractTypeComputationState.java:346)
	at org.eclipse.xtext.xbase.typesystem.computation.XbaseTypeComputer._computeTypes(XbaseTypeComputer.java:848)
	at org.uqbar.HoopeTypeComputer.computeTypes(HoopeTypeComputer.java:70)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.doComputeTypes(AbstractTypeComputationState.java:119)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.computeTypes(AbstractTypeComputationState.java:108)
	at org.eclipse.xtext.xbase.typesystem.computation.XbaseTypeComputer._computeTypes(XbaseTypeComputer.java:292)
	at org.uqbar.HoopeTypeComputer.computeTypes(HoopeTypeComputer.java:88)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.doComputeTypes(AbstractTypeComputationState.java:119)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.computeTypes(AbstractTypeComputationState.java:108)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractRootTypeComputationState.computeTypes(AbstractRootTypeComputationState.java:36)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._computeTypes(LogicalContainerAwareReentrantTypeResolver.java:512)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:422)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeMemberTypes(LogicalContainerAwareReentrantTypeResolver.java:583)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._computeTypes(LogicalContainerAwareReentrantTypeResolver.java:572)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:416)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:411)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:160)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:147)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultBatchTypeResolver$1.reentrantResolve(DefaultBatchTypeResolver.java:122)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getDelegate(CompoundReentrantTypeResolver.java:79)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getDelegate(CompoundReentrantTypeResolver.java:114)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.getActualType(CompoundReentrantTypeResolver.java:106)
	at org.eclipse.xtext.xbase.typesystem.internal.ForwardingResolvedTypes.getActualType(ForwardingResolvedTypes.java:39)
	at org.eclipse.xtext.xbase.typesystem.InferredTypeIndicator.getTypeReference(InferredTypeIndicator.java:78)
	at org.eclipse.xtext.xtype.impl.XComputedTypeReferenceImplCustom.getEquivalent(XComputedTypeReferenceImplCustom.java:46)
	at org.eclipse.xtext.common.types.impl.JvmSpecializedTypeReferenceImplCustom.getType(JvmSpecializedTypeReferenceImplCustom.java:23)
	at org.eclipse.xtext.xbase.compiler.ErrorSafeExtensions.serializeSafely(ErrorSafeExtensions.java:210)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateParameter(JvmModelGenerator.java:1066)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateParameters(JvmModelGenerator.java:1038)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateMember(JvmModelGenerator.java:857)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateMember(JvmModelGenerator.java:1880)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$2.apply(JvmModelGenerator.java:288)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$2.apply(JvmModelGenerator.java:1)
	at org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_doubleArrow(ObjectExtensions.java:139)
	at org.eclipse.xtext.xbase.compiler.LoopExtensions$1.apply(LoopExtensions.java:39)
	at org.eclipse.xtext.xbase.lib.IterableExtensions.forEach(IterableExtensions.java:399)
	at org.eclipse.xtext.xbase.compiler.LoopExtensions.forEach(LoopExtensions.java:42)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateBody(JvmModelGenerator.java:292)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateBody(JvmModelGenerator.java:1852)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateType(JvmModelGenerator.java:211)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._internalDoGenerate(JvmModelGenerator.java:202)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.internalDoGenerate(JvmModelGenerator.java:1835)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.doGenerate(JvmModelGenerator.java:183)
	at org.eclipse.xtext.builder.BuilderParticipant.handleChangedContents(BuilderParticipant.java:299)
	at org.eclipse.xtext.builder.BuilderParticipant.build(BuilderParticipant.java:229)
	at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:186)
	at org.eclipse.xtext.builder.impl.XtextBuilder.incrementalBuild(XtextBuilder.java:162)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:95)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


It's running on Eclipse 4.3 and Xtext 2.4.2.

Any clue? Sinc domain model examples using jvminferrer have mandatory type declaration, perhaps this feature is not available.

Thanks in advance and best regards!
Miguel

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178499 is a reply to message #1178440] Sat, 09 November 2013 18:02 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
Hi,

you are not actually doing that is done in the domain model example.
there is simply called org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.inferredType()

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178517 is a reply to message #1178499] Sat, 09 November 2013 18:20 Go to previous messageGo to next message
Miguel Carboni is currently offline Miguel CarboniFriend
Messages: 8
Registered: September 2013
Junior Member
I understand I'm not doing the samething, yet is it possible to what I'm trying?

I've upgraded xtext to 2.4.3.

Thanks,
Miguel

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178552 is a reply to message #1178517] Sat, 09 November 2013 18:47 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
Hi,

can you simply try it?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178558 is a reply to message #1178552] Sat, 09 November 2013 18:55 Go to previous messageGo to next message
Miguel Carboni is currently offline Miguel CarboniFriend
Messages: 8
Registered: September 2013
Junior Member
I've tried this:

					Property: {
						
						val type = feature.type?: inferredType
						
						members += feature.toField(feature.name, type) [
							initializer = feature.value
						]
						members += feature.toGetter(feature.name, type)
						members += feature.toObservedSetter(feature.name, type)
					}


And get the following Exception:

org.eclipse.emf.common.util.WrappedException: java.lang.IllegalStateException: equivalent could not be computed
	at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:129)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver.resolveTypes(CachingBatchTypeResolver.java:58)
	at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:45)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:142)
	at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:511)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(ResourceValidatorImpl.java:155)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:68)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.addMarkers(DefaultResourceUIValidatorExtension.java:60)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.updateValidationMarkers(DefaultResourceUIValidatorExtension.java:45)
	at org.eclipse.xtext.builder.builderState.MarkerUpdaterImpl.processDelta(MarkerUpdaterImpl.java:74)
	at org.eclipse.xtext.builder.builderState.MarkerUpdaterImpl.updateMarkers(MarkerUpdaterImpl.java:59)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.updateMarkers(AbstractBuilderState.java:80)
	at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:266)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:111)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:184)
	at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:210)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:89)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: java.lang.IllegalStateException: equivalent could not be computed
	at org.eclipse.xtext.xbase.typesystem.InferredTypeIndicator.getTypeReference(InferredTypeIndicator.java:84)
	at org.eclipse.xtext.xtype.impl.XComputedTypeReferenceImplCustom.getEquivalent(XComputedTypeReferenceImplCustom.java:46)
	at org.eclipse.xtext.common.types.impl.JvmSpecializedTypeReferenceImplCustom.getType(JvmSpecializedTypeReferenceImplCustom.java:23)
	at org.eclipse.xtext.xbase.scoping.batch.BucketedEObjectDescription.computeShadowingKey(BucketedEObjectDescription.java:79)
	at org.eclipse.xtext.xbase.scoping.batch.BucketedEObjectDescription.getShadowingKey(BucketedEObjectDescription.java:62)
	at org.eclipse.xtext.xbase.scoping.batch.AbstractSessionBasedScope.getShadowingKey(AbstractSessionBasedScope.java:169)
	at org.eclipse.xtext.xbase.scoping.batch.AbstractSessionBasedScope.isShadowed(AbstractSessionBasedScope.java:179)
	at org.eclipse.xtext.scoping.impl.AbstractScope$ParentIterable.apply(AbstractScope.java:67)
	at org.eclipse.xtext.scoping.impl.AbstractScope$ParentIterable.apply(AbstractScope.java:1)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
	at com.google.common.collect.Iterators$5.hasNext(Iterators.java:539)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.getLinkingCandidates(AbstractTypeComputationState.java:346)
	at org.eclipse.xtext.xbase.typesystem.computation.XbaseTypeComputer._computeTypes(XbaseTypeComputer.java:859)
	at org.uqbar.HoopeTypeComputer.computeTypes(HoopeTypeComputer.java:70)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.doComputeTypes(AbstractTypeComputationState.java:119)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.computeTypes(AbstractTypeComputationState.java:108)
	at org.eclipse.xtext.xbase.typesystem.computation.XbaseTypeComputer._computeTypes(XbaseTypeComputer.java:293)
	at org.uqbar.HoopeTypeComputer.computeTypes(HoopeTypeComputer.java:88)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.doComputeTypes(AbstractTypeComputationState.java:119)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractTypeComputationState.computeTypes(AbstractTypeComputationState.java:108)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractRootTypeComputationState.computeTypes(AbstractRootTypeComputationState.java:36)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._computeTypes(LogicalContainerAwareReentrantTypeResolver.java:512)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:422)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeMemberTypes(LogicalContainerAwareReentrantTypeResolver.java:583)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver._computeTypes(LogicalContainerAwareReentrantTypeResolver.java:572)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:416)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:411)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:210)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:197)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultBatchTypeResolver$1.reentrantResolve(DefaultBatchTypeResolver.java:122)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.reentrantResolve(CompoundReentrantTypeResolver.java:65)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.delegate(CachingBatchTypeResolver.java:114)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:61)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:1)
	at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36)
	at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:127)
	... 28 more

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1178610 is a reply to message #1178558] Sat, 09 November 2013 19:43 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
strange. sounds like a bug to me

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: [Xbase] getting the result type of an expression during inferring [message #1181454 is a reply to message #1178610] Mon, 11 November 2013 16:10 Go to previous message
Matthias Spiller is currently offline Matthias SpillerFriend
Messages: 13
Registered: September 2013
Junior Member
I also suffer from this.
It seems to happen when you create a field (with inferredType) together with getter and/or setter.

I think this is an incarnation of https://bugs.eclipse.org/bugs/show_bug.cgi?id=408323.
Any known workaround?

Report message to a moderator

Previous Topic:Conflict between xtend and xtext language, model inferrer and dependencies?
Next Topic:Create an Eclipse product
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Apr 16 22:30:15 GMT 2024

Powered by FUDForum. Page generated in 2.61091 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