eclipse-viatra / org.eclipse.viatra

Main components of the VIATRA framework
https://eclipse.dev/viatra
Eclipse Public License 2.0
0 stars 1 forks source link

EMF Generics not supported in VQL #11

Open eclipse-viatra-bot opened 6 months ago

eclipse-viatra-bot commented 6 months ago

| --- | --- | | Bugzilla Link | 404652 | | Status | ASSIGNED | | Importance | P3 major | | Reported | Mar 31, 2013 21:59 EDT | | Modified | May 27, 2019 07:45 EDT | | Version | oldinquery | | Reporter | Istvan David |

Description

Model elements of type Class<? extends something> result in a java.lang.Class type in the generated evaluateXExpression() method instead of something meaningful. (E.g. "?" or the given type itself.) This causes faulty code (since "T cannot be resolved to a type").

In my particular case the model element is: Class<? extends Event> eventType.\ But the generated code looks like this:\ java.lang.Class eventGuardType = (java.lang.Class)tuple.get(eventGuardTypePosition);

Replacing the type parameter with the appropriate one solves the problem, of course. I.e. both\ -java.lang.Class<?> eventGuardType = (...), and\ -java.lang.Class<? extends Event> eventGuardType = (...)\ are OK.

If this is a reasonable behavior (i.e. because of a shortcoming of Xbase, or EMF, etc), it would be nice to mention it in the documentation, or perhaps a warning marker could be placed on the related element in the query.

eclipse-viatra-bot commented 6 months ago

By Istvan Rath on Apr 01, 2013 05:11

A clarification: these special Java types can be assigned to attributes.

(In reply to comment #0)

Model elements of type Class<? extends something> result in a java.lang.Class type in the generated evaluateXExpression() method instead of something meaningful. (E.g. "?" or the given type itself.) This causes faulty code (since "T cannot be resolved to a type").

In my particular case the model element is: Class<? extends Event> eventType. But the generated code looks like this: java.lang.Class eventGuardType = (java.lang.Class)tuple.get(eventGuardTypePosition);

Replacing the type parameter with the appropriate one solves the problem, of course. I.e. both -java.lang.Class<?> eventGuardType = (...), and -java.lang.Class<? extends Event> eventGuardType = (...) are OK.

If this is a reasonable behavior (i.e. because of a shortcoming of Xbase, or EMF, etc), it would be nice to mention it in the documentation, or perhaps a warning marker could be placed on the related element in the query.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Apr 01, 2013 12:00

As far as I remember, the Xbase model inferrer API allows putting generics information into the generated models, but in most cases we don't utilize that. This must be the source of the issue.

Istvan (David :) ), could you create some small example that reproduces this issue (just to make sure, we try to fix the correct issue :) ). Thanks.

eclipse-viatra-bot commented 6 months ago

By Istvan David on Apr 01, 2013 16:16

Sure thing; see the attached zip file (hu.bme.mit.incquery.cep.zip). It contains a plugin and a test plugin as a fragment for the former one.\ Steps to reproduce the issue:

  1. Get a running Eclipse with IQ.
  2. Import both plugin projects.
  3. Change something in the "queries.eiq" file in the test plugin. (E.g. add a dummy pattern, etc.)
  4. Check the generated code. The pattern "enabledTransition" is the one responsible for the issue. There must be a "EnabledTransitionEvaluator1_1.java" file in the "hu.bme.mit.incquery.cep.tests.testcasesmqueries.enabledtransition" package; look for the type of the "eventGuardType" variable in its "evaluateXExpression()" method.

As far as I can tell, the problem arises from the "EMFPatternLanguageJvmModelInferrerUtil.calculateType()" method. If you can give me some pointers I'll try to look into in on my own and submit a patch if succeeded.

(In reply to comment #2)

As far as I remember, the Xbase model inferrer API allows putting generics information into the generated models, but in most cases we don't utilize that. This must be the source of the issue.

Istvan (David :) ), could you create some small example that reproduces this issue (just to make sure, we try to fix the correct issue :) ). Thanks.

eclipse-viatra-bot commented 6 months ago

By Istvan David on Apr 01, 2013 16:17

Created attachment 229216 Example projects to reproduce issue #404652

:compression: hu.bme.mit.incquery.cep.zip

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Apr 03, 2013 12:44

Thanks for the reproduction. I have taken a look and found out that there are two different problems we need to solve this issue 1) the TypeProvider interface does not handle EMF generics, the type it calculates does not contain the generics information 2) Additionally, your referred method indeed does not output the generics as required, so that needs to be changed as well.\ \ I have started working on the solution, but at this point, I found out we will need to change a large number of things inside the Type Provider to propagate this information, so I do not have a working solution yet.

eclipse-viatra-bot commented 6 months ago

By Istvan Rath on Apr 03, 2014 10:50

Assigning more complex issues to 0.8-M4. Please discuss if feasible or needs to be pushed to post-0.8.

eclipse-viatra-bot commented 6 months ago

By Istvan Rath on Apr 16, 2014 09:44

Postponing.

eclipse-viatra-bot commented 6 months ago

By Gabor Bergmann on May 28, 2014 12:45

These bugs will not be handled in this milestone

eclipse-viatra-bot commented 6 months ago

By Istvan Rath on Jun 04, 2014 10:45

Postponing to next development cycle.

eclipse-viatra-bot commented 6 months ago

By Istvan Rath on Sep 29, 2015 08:41

Pushing these issues to the 1.2 timeframe.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Mar 17, 2016 08:27

Replaced target milestone from incquery with VIATRA

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Mar 17, 2016 08:47

Postponed tickets to 1.3

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on May 26, 2016 08:44

1.3 M1 already passed.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Jun 15, 2016 10:41

The new type inferrer from bug 437972 could be extended to also support generic EMF types, but that is not reasonable for 1.3, especially as we have to plan how to handle this case in the runtime (Rete and LS matchers as well).

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Jan 25, 2017 07:45

Mass move of tickets we are not expecting to solve soon to the Future milestone.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Oct 04, 2017 05:26

Moving potential tasks from future to 2.0.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on Feb 08, 2018 07:21

Postponing to a future release.

eclipse-viatra-bot commented 6 months ago

By Zoltan Ujhelyi on May 27, 2019 07:45

Postponing tickets to FUTURE until effort is allocated to fix them.