Uwe Ritzmann

During implementation of QvtOperationalResourceImpl.save() I came across a few gaps that the QVTo Parser leaves behind in the AST.

Bug 489092 Helper.isQuery not set by QvtOperationalVisitorCS.java

The attribute isQuery of AST node Helper is not set, although the parser puts it into the respective CST node.

That bug I could fix in my development environment with few lines of code in QvtOperationalVisitorCS.visitMappingDeclarationCS(.,.,.):

    if ( operation instanceof Helper )
        {
            Helper helper = (Helper) operation;
            helper.setIsQuery(mappingDeclarationCS.isIsQuery());
        }

Without this attribute in the AST each original Query is treated as Helper.

Bug 489093 MappingCallExp.setOperationCode() not called in QvtOperationalVisitorCS.createMappingCallExp()

I came across this bug because my unparser chooses from ambiguous notation variants always the explicit long variant. That would be the second of this both lines:

    inModel.rootObjects()[EPackage]->map p2p();
    inModel.rootObjects()[EPackage]->xcollect(tempP|tempP.map p2p());

The parser seems to not handle both sufficiently identical. In one case he calls QvtOperationalVisitorCS.createMappingCallExp(), in the other not. And the mentioned method misses a simple:

    mappingCallExp.setOperationCode(operationCallExp.getOperationCode());