Uwe Ritzmann

Während der Entwicklung von QvtOperationalResourceImpl.save() stieß ich auf wenige Lücken, die der QVTo-Parser im AST läßt.

Bug 489092 Helper.isQuery not set by QvtOperationalVisitorCS.java

Der AST-Knoten Helper bekommt sein Attribut isQuery nicht gesetzt, obschon der Parser dies in den entsprechenden CST-Knoten ablegt.

In meiner Entwicklungsumgebung konnte ich den Fehler durch wenige Zeilen in QvtOperationalVisitorCS.visitMappingDeclarationCS(.,.,.) beheben:

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

Ohne dies Attribut wird im AST jede ursprüngliche Query als Helper interpretiert.

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

Auf diesen Fehler stieß ich, da meine Unparser bei mehrdeutigen Schreibweisen, immer die "Langform" wählt, von den folgenden zwei Zeilen also die Zweite

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

Der Parser scheint diese aber nicht hinreichen gleich zu behandeln. In einem Fall läuft er durch QvtOperationalVisitorCS.createMappingCallExp(), in dem anderen nicht. Und in der genannten Methode fehlt ein einfaches:

    mappingCallExp.setOperationCode(operationCallExp.getOperationCode());