fix CoCo error 0x10AA1 - imported and quoted PartDef resolution

[linggd]

The Apollo-11 models can already be parsed #146 . The symbol resolution and CoCos are adapted so that the models also pass the CoCos.

2 of 5 CoCo errors addressed

0x10AA1 — PartDef resolution

Apollo introduced several cases that were not covered by the previous models:

• PartUsages with both : typing and :> specialization. The CoCo incorrectly checked both as PartDefs.,
• Imported PartDefs. Import-aware resolution existed for resolveType(), but not for resolvePartDef().,
• Imports declared in the current package scope. The existing logic only checked the enclosing scope and therefore missed these imports.,
• Quoted names containing dots, such as 'Roger B. Chaffee'. The dots were incorrectly interpreted as qualification separators.,

These cases exposed missing or incorrect behavior in the PartDef resolution.

Changelog

Fix

• use resolveType() instead of resolvePartDef() in PartTypeDefinitionExistsCoCo.
• Collect imports from the current scope before continuing resolution in the enclosing scope.

[mathias-pfeiffer]

Die Änderungen an dieser Datei scheinen zu sein:

##### Changed

* ApolloTest baut jetzt auch Symboltabelle auf und wurde vorbereitet fürs Testen der CoCos
    - Deswegen von Paket "parser" nach "cocos" verschoben

Bitte in einen getrennten MR packen

[mathias-pfeiffer]

Die Änderungen an dieser Datei scheinen zu sein:

##### Fixed

* Anonyme PartUsages haben zu Crashes bei der Überprüfung der Eindeutigkeit des Namens geführt
   - Werden jetzt von der CoCo ignoriert

Bitte in einen getrennten MR packen

[mathias-pfeiffer]

Diese Änderung ist nicht ausreichend erklärt. Könntest du bitte ein minimalen Beispielmodell angeben, für das diese CoCo fälschlicherweise einen Fehler meldet, in: https://git.rwth-aachen.de/montibelle/frontend/transformer/sysmltransformer/-/work_items/323

Die Änderung wir aus diesem MR entfernt. Dann wird im angegebenen Ticket das Problem festgestellt, sende mir auf Slack einen Nachricht, sobald ich mir das anschauen kann. Danach klären wir, wie die Lösung aussehen wird.

[mathias-pfeiffer]

Die Änderungen hier scheinen u.A. auf diese Zeile zurückführbar zu sein:

Imported PartDefs. Import-aware resolution existed for resolveType(), but not for resolvePartDef().,

Wir werden für diesen Teil des Problems die entsprechenden Stellen (zB. die CoCo PartTypeDefExists) so umbauen, dass sie mit resolveType statt resolvePartDef arbeiten. Die Änderungen dazu hier werden erstmal wieder rückgängig gemacht

[mathias-pfeiffer]

Dieser Spezialfall ist nicht ausreichend diskutiert, entfernen hier alles dazu und klären zuerst alle Probleme und mögliche Lösungen: https://git.rwth-aachen.de/montibelle/frontend/transformer/sysmltransformer/-/work_items/324

[mathias-pfeiffer]

@linggd bitte erkläre kurz was mit "Imports declared in the current package scope. The existing logic only checked the enclosing scope and therefore missed these imports.," gemeint ist und welche der Änderungen zu diesem Punkt gehören. Bis auf diesen Punkt wurden alle anderen Inhalte in eigene Tickets verlagert und werden in getrennten PRs behandelt.

[linggd]

@linggd bitte erkläre kurz was mit "Imports declared in the current package scope. The existing logic only checked the enclosing scope and therefore missed these imports.," gemeint ist und welche der Änderungen zu diesem Punkt gehören. Bis auf diesen Punkt wurden alle anderen Inhalte in eigene Tickets verlagert und werden in getrennten PRs behandelt.

Erklärung

Die Methode continueTypeWithEnclosingScope(...) in ISysMLScope.java hat Imports immer im Enclosing Scope gesucht :

if(getEnclosingScope().isPresentAstNode()) {
        var visitor = new SysMLPartsVisitor2() {
          @Override
          public void visit(ASTSysMLImportStatement node) {
            if (getEnclosingScope().equals(node.getEnclosingScope())) {
              importStatements.add(new ImportStatement(node.getMCQualifiedName().getQName(),
                  node.isStar() || node.isRecursive()));
            }
          }
        };
        var traverser = SysMLv2Mill.inheritanceTraverser();
        traverser.add4SysMLParts(visitor);
        getEnclosingScope().getAstNode().accept(traverser);
      }

Bei diesem Modell funktioniert das:

package VehiclePackage {
  import Definitions::*;

  part def Vehicle {
    part wheel : Wheel;
  }
}

Beim Auflösen von Wheel ist der aktuelle Scope Vehicle. Durch den Aufruf getEnclosingScope().getAstNode().accept(traverser); wird anschließend der enclosing Scope VehiclePackage traversiert. Dort steht der Import, deshalb wird er gefunden.

Im Apollo-Modell liegt aber der Part direkt im Package:

package StakeholderPackage {
  private import CoSMAPackage::*;

  part AstronautFamilies : Stakeholder;
}

Hier wird Stakeholder aus dem CoSMAPackage importiert.

Beim Auflösen von Stakeholder ist der aktuelle Scope schon StakeholderPackage. Der Enclosing Scope ist dann der Artifact Scope.

Der Import steht aber im aktuellen StakeholderPackage. Die alte Implementierung hat diesen Import deshalb nicht gefunden.

Die neue Implementierung sucht zuerst die Imports im aktuellen Scope und geht danach weiter zum Enclosing Scope.

Die Änderung gehört zu :

collectImportsFromScope(...)

[mathias-pfeiffer]

Die Methode continueTypeWithEnclosingScope(...) in ISysMLScope.java hat Imports immer im Enclosing Scope gesucht

Dh. du hast einen Fehler in continueTypeWithEnclosingScope entdeckt, aber keine Änderung am Code gemacht:

Kannst du das noch klarstellen?

[linggd]

Die Methode continueTypeWithEnclosingScope(...) in ISysMLScope.java hat Imports immer im Enclosing Scope gesucht

Dh. du hast einen Fehler in continueTypeWithEnclosingScope entdeckt, aber keine Änderung am Code gemacht:

Kannst du das noch klarstellen?

Die ursprüngliche CoCo hat resolvePartDef(...) verwendet. Deshalb hatte ich die Behandlung der Imports aus dem aktuellen Scope zunächst in continuePartDefWithEnclosingScope(...) ergänzt.
Es war mein Fehler, dass ich die Implementierung noch nicht auch auf continueTypeWithEnclosingScope(...) übertragen hatte.

Nach deinem Hinweis, dass die CoCo stattdessen resolveType(...) verwenden soll, läuft die Auflösung jedoch über continueTypeWithEnclosingScope(...). Deshalb bezieht sich meine spätere Erklärung auf continueTypeWithEnclosingScope(...).

Ich werde die entsprechende Änderung auch in continueTypeWithEnclosingScope(...) umsetzen.