Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 318653

Summary:

QVTo: "access transformation" triggers name resolution errors (QvtOperationalVisitorCS_OperationNotFound_ERROR_)

Product:

[Modeling] QVTo

Reporter:

Nicolas Rouquette <nicolas.f.rouquette>

Component:

Engine

Assignee:

Sergey Boyko <serg.boyko2011>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

serg.boyko2011

Version:

unspecified

Target Milestone:

---

Hardware:

Macintosh

OS:

Mac OS X

Whiteboard:

R3_0_maintenance

Attachments:

Description	Flags
This library defines a simple query: addSuffix(String) : String	none
Standalone version of Lib.qvto	none
A simple transformation that uses Lib::addSuffix	none
B1 does not access A; it compiles cleanly.	none
B2 accesses A and it produces an error	none
Proposed fix.	none
An input model to test B.qvto	none
The expected state of the input model after successful completion of B.qvto	none
Proposed fix	none

Description Nicolas Rouquette

2010-07-01 19:21:53 EDT

With the CVS HEAD of QVTo on Helios, there is a strange phenomenon when transformations are composed using the access mechanism (see QVT specification, clause 8.1.11).
I'm attaching an example to demonstrate.

Comment 1 Nicolas Rouquette

2010-07-01 19:23:45 EDT

Created attachment 173259 [details]
This library defines a simple query: addSuffix(String) : String

Comment 2 Nicolas Rouquette

2010-07-01 19:26:02 EDT

Created attachment 173260 [details]
Standalone version of Lib.qvto

Comment 3 Nicolas Rouquette

2010-07-01 19:26:44 EDT

Created attachment 173261 [details]
A simple transformation that uses Lib::addSuffix

Comment 4 Nicolas Rouquette

2010-07-01 19:27:37 EDT

Created attachment 173262 [details]
B1 does not access A; it compiles cleanly.

Comment 5 Nicolas Rouquette

2010-07-01 19:28:50 EDT

Created attachment 173263 [details]
B2 accesses A and it produces an error

Cannot find operation (addSuffix(String)) for the type (null)

Comment 6 Nicolas Rouquette

2010-07-01 19:31:30 EDT

To reproduce the bug, get all 4 files:
Lib.qvto (the second attachment)
A.qvto
B1.qvto // parse ok
B2.qvto // parse error.

The difference between B1 & B2 is very little; B2 accesses A; B1 doesn't.
It is very odd that adding a transformation access would interfere with the name resolution mechanism to find operations.

Comment 7 Nicolas Rouquette

2010-07-02 21:15:38 EDT

Created attachment 173339 [details]
Proposed fix.

The bug is a bit subtle.  The parser logic was ignoring all import statements whenever the module had any module usage (i.e., transformation <M1> [(access|extends) (transformation|library) <M2>]+)
The corrected logic imports a given module only if there is no usage for the same module where equality for module references (import or usage) is predicated on the two module references having the same module pathname.

Comment 8 Nicolas Rouquette

2010-07-02 21:16:43 EDT

Created attachment 173340 [details]
An input model to test B.qvto

Comment 9 Nicolas Rouquette

2010-07-02 21:17:54 EDT

Created attachment 173341 [details]
The expected state of the input model after successful completion of B.qvto

Comment 10 Nicolas Rouquette

2010-07-02 21:19:03 EDT

With the fix, QVTo works properly in my environment (Helios + QVTo/QVTd from CVS Head)

Comment 11 Sergey Boyko

2010-07-14 17:03:53 EDT

Created attachment 174348 [details]
Proposed fix

Fixed logic for implicit extends semantic now clearly expressed. When such import is detected then temporary extension model usage creates.

Comment 12 Sergey Boyko

2010-07-14 17:06:41 EDT

Fix is committed in R3_0_maintenance branch.