Community
Participate
Working Groups
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.
Created attachment 173259 [details] This library defines a simple query: addSuffix(String) : String
Created attachment 173260 [details] Standalone version of Lib.qvto
Created attachment 173261 [details] A simple transformation that uses Lib::addSuffix
Created attachment 173262 [details] B1 does not access A; it compiles cleanly.
Created attachment 173263 [details] B2 accesses A and it produces an error Cannot find operation (addSuffix(String)) for the type (null)
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.
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.
Created attachment 173340 [details] An input model to test B.qvto
Created attachment 173341 [details] The expected state of the input model after successful completion of B.qvto
With the fix, QVTo works properly in my environment (Helios + QVTo/QVTd from CVS Head)
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.
Fix is committed in R3_0_maintenance branch.
