107 lines
9.0 KiB
Markdown
107 lines
9.0 KiB
Markdown
# Implementierungsnachweis — 05.09.2026
|
||
|
||
Change: `projektmodule-und-kompilat`, Ausgangscommit `58b1f62`.
|
||
|
||
**Abschließende Verifikation:** [review.md](review.md) bestätigt die Behebung
|
||
aller sechs ursprünglichen und aller zusätzlich reproduzierten Befunde.
|
||
Der [erste Review](review-initial.md) bleibt als historischer Nachweis erhalten.
|
||
|
||
Alle zwölf Tasks (sieben Implementierungs- und fünf Review-Aufgaben) sind
|
||
umgesetzt. F09, F10, F11 und F24 sind im Arbeitsbaum bearbeitet; die
|
||
Hauptspec-Synchronisierung und Archivierung sind am 05.09.2026 abgeschlossen. Die Abnahme
|
||
umfasst alle sieben Delta-Requirements mit ihren 21 Szenarien.
|
||
|
||
## Umsetzung
|
||
|
||
| Task / Befund | Umsetzung und Nachweis |
|
||
| --- | --- |
|
||
| 1.1 / F10 | `SourceUnit`/`SourceSegment` erhalten Modul, Datei und physische Zeile vor dem Parsen. Lexer- und Parserpositionen werden vor der Semantik den Originalquellen zugeordnet. CLI-Tests prüfen Compile-/Runtimefehler aus `lib.bas:2`, verschachtelten Includes und dem Codeabschnitt eines entfernten FRM. Auch leere Quellen funktionieren. |
|
||
| 1.2 / F09 | Module werden getrennt aufgelöst und danach numerisch verbunden. Lokale Prozeduren und Controls haben Vorrang, `Form!Control` sucht direkt im angegebenen Formular. Eltern-IDs ersetzen Namensvergleiche auch bei Frames, Menüs, Optionsgruppen und Geometrie. Zwei Form_Load-Prozeduren initialisieren ihre jeweiligen Text1-Controls unabhängig; echte SUB-/CONST-/TYPE-Duplikate im selben Modul bleiben Fehler. |
|
||
| 2.1 / F11 | TBC 4 enthält Module/Quellen, vollständige Parameter- und Rückgabetypen, Locals, Forms-Instanzen mit Eigenschaften, Designindizes und Eltern-IDs sowie das Startformular. `Vm::new` stellt diesen Anfangszustand her. Bytegleicher Rundlauf und Ausführung mit zwei Formularen und Designarrays 0/2 sind geprüft. |
|
||
| 2.2 / F10 | `Source` plus `Stmt` liefern Datei/Spalte/physische Zeile. `InitStmt` erhält dieselben Informationen für globale Initialisierungen, ohne vorzeitig Ereignisse zuzustellen. Breakpoints verwenden Modul-ID und Zeile. Einzelschritt, Variableninspektion und Fortsetzen bleiben möglich. Numerische Labels führen separat `SetErl`; DEF FN erhält den tatsächlichen Quellort. |
|
||
| 2.3 / F11 | `tbc run` lädt TBC direkt. Der CLI-Test baut ein Projekt, entfernt alle BAS-/BI-/FRM-/MAK-Dateien und vergleicht die Ausgabe des Kompilats mit der Quellausführung (`hello`, `world`, `7`). Ein zweiter Fall erhält nach Entfernen des FRM den Fehlerort `error.frm:6:1`. Versionen 1, 2, 3, 5 und 32767 werden ausdrücklich benannt und abgewiesen. |
|
||
| 3.1 / F24 | [TBVM-Format](../../../../docs/tbvm-design.md) dokumentiert alle neun Abschnitte und alle 153 Opcodes einzeln mit Operanden, Encodingbreiten und Kennungen. Der Compile-Benchmark übersetzt und verbindet nun tatsächlich ein Projekt mit 20 Modulen. |
|
||
| 3.2 | Alle Delta-Requirement-Blöcke behalten ihre bisherigen Szenarien. Neue Szenarien und die Implementierungsentscheidungen D1–D4 wurden gegen die unten genannten Tests und Codepfade abgeglichen. OpenSpec- und Diff-Prüfung bestanden. |
|
||
|
||
## Projektgrenzen und ergänzende Regressionen
|
||
|
||
Der Projektlink versetzt Prozedur-, Slot-, TYPE-, String-, DATA- und
|
||
Sprungtabellenreferenzen. Hauptprogramminitialisierungen aller Mitglieder
|
||
laufen vor der ersten Ereigniszustellung; die übrigen Modulrümpfe folgen der
|
||
Projektreihenfolge. Eindeutige externe Prozeduren werden als Deklarationen
|
||
importiert, lokale Namen bleiben erhalten. Eindeutige fremde Konstanten und
|
||
TYPEs bleiben als Kompatibilitätsregel sichtbar. Es wird kein Quelltext zur
|
||
Unterdrückung von Duplikaten gelöscht.
|
||
|
||
Geprüft sind wiederholt eingebundene Konstanten, gleichnamige lokale SUBs,
|
||
modullokales SHARED, gemeinsame COMMON-Skalare und unterschiedliches OPTION
|
||
BASE. Modulhandler werden getrennt gespeichert: ON ERROR GOTO 0 in der
|
||
Bibliothek deaktiviert den Handler des Aufrufers nicht. Bestehende ERR-/ERL-
|
||
und RESUME-Korpustests bestehen unverändert.
|
||
|
||
Der Signaturtest übergibt ein INTEGER-Array, einen UDT und einen Skalar an
|
||
eine Funktion in einem anderen Modul. Er prüft Rückgabetyp, Array-/BYREF-
|
||
Merkmale, Ausgabe und Rückwirkung einer UDT-Feldänderung auf den Aufrufer.
|
||
Die dabei gefundene Inkonsistenz zwischen UDT-Argument und Parameter wurde
|
||
im gemeinsamen Semantikpfad behoben. Bekannte externe Dialogdeklarationen
|
||
funktionieren auch mit qualifizierten Prozedurnamen. ISAM-OPEN verwendet mit
|
||
`PushUdtId` eine explizit versetzbare TYPE-Referenz; der Test vergleicht sie
|
||
nach dem Rundlauf mit dem tatsächlichen UDT-Index.
|
||
|
||
Der Loader weist abgeschnittene Dateien an jedem Byteoffset, ungültige
|
||
Flags/Abschnittsgrößen, doppelte Abschnitte sowie ungültige Quell-, Modul-,
|
||
Prozedur- und Elternreferenzen ab. Inkonsistente Signaturen, doppelte
|
||
Anfangseigenschaften, falsche Property-Typen und abweichende Designindizes
|
||
werden vor dem VM-Start geprüft. Das ersetzt keinen vollständigen
|
||
Stackverifizierer für beliebigen fremden Bytecode.
|
||
|
||
## Requirement- und Szenarioabgleich
|
||
|
||
Die neuen ausführbaren Nachweise liegen in
|
||
[VM-Projekttests](../../../../crates/tb-vm/tests/project.rs) und
|
||
[CLI-Projekttests](../../../../crates/tb-cli/tests/project.rs).
|
||
Die folgende Tabelle führt auch die erhaltenen Szenarien auf; bestehende
|
||
Tests werden durch neue Mehrmodul- und Include-Proben ergänzt.
|
||
|
||
| Requirement | Szenarien und Belege |
|
||
| --- | --- |
|
||
| Monomorpher Opcode-Satz | Gemischter Ausdruck: `codegen::tests::ausdruck_monomorph_mit_conv`; aufgelöste Namen: `sema::tests::hir_slots_aufgeloest` und die numerisch verbundenen Projektaufrufe. Vollständigkeit der Dokumentation zusätzlich gegen das `instrs!`-Makro geprüft. |
|
||
| .tbc-Containerformat | Roundtrip: mehrere VM-Projekttests vergleichen die gesamten Bytes; unbekannte Version: CLI-Versionstests; Formularwerte: CLI-Ausgabe `hello` und `world` nach Entfernen sämtlicher Quellen. |
|
||
| Zeilentabelle für Fehlerortung | Physische Fehlerzeile: Stmt-/Source-Zuordnung und CLI-Fehlerproben; Projektbibliothek: `lib.bas:2:5`, Include: `inner.bi:2:5`; zusätzlich InitStmt-, DEF-FN- und FRM-Codepositionen. |
|
||
| Formulare und Steuerelemente als benannte Objekte | Lesen/Schreiben: bestehender VM-Test `objektzugriff_laeuft_ueber_objekt_und_eigenschaftsindex`; keine Standardeigenschaft: `sema::tests::eigenschaftstyp_schreibbarkeit_bang_und_hir_index`; Wertebereich: `forms::tests::defaults_bereich_und_implizites_laden` prüft Check1.Value = 3 → Fehler 5; unabhängige Werte: zwei Formulare mit Text1 und eigenem Form_Load im neuen Projekttest. |
|
||
| Diagnostik mit Vorbild-Meldungen | Exakte Position: SourcePos bleibt 1-basiert; neue Tests prüfen Datei, Zeile und Spalte. Include-Diagnose: sowohl direktes SourceSegment als auch verschachtelte CLI-Expansion liefern die ursprüngliche Position des Typfehlers. |
|
||
| Objektzugriffe in Grammatik und Semantik | Unbekanntes Objekt/Eigenschaft und Eigenschaftstyp: bestehende Semantiktests für Text9.Text, Text1.Farbe und Text1.Text = 5; TYPEOF: `typeof_form_control_und_form_metabefehl`; gleichnamige Controls: Form1!Text1/Form2!Text1 sowie lokale Text1-Zugriffe beider Form_Load-Rümpfe. |
|
||
| Unterbrechbare step()-Ausführung | Breakpoint und Inspektion: vorhandene VM-Tests plus neuer Modulbreakpoint; gleiche Zeile in zwei Modulen: Modul A passiert Zeile 2, Modul B hält dort. Fortsetzen im Einzelschritt erhält `nested.bi:2`, physische Spalte 5 und getrenntes ERL = 200. |
|
||
|
||
## Ausgeführte Abnahme
|
||
|
||
- `cargo test --workspace`: **453 bestanden, 0 fehlgeschlagen, 1 ignoriert**.
|
||
Der ignorierte Golden-Generator wurde nicht ausgeführt; Sollausgaben blieben unverändert.
|
||
- `cargo clippy --workspace --all-targets --all-features -- -D warnings`: bestanden.
|
||
- `cargo fmt --all -- --check`: bestanden.
|
||
- `cargo bench -p tb-vm --bench compile`: 508 Zeilen **0,56 ms** (Budget 50 ms);
|
||
49.760 Zeilen in 20 verbundenen Modulen **77 ms** (Budget 1000 ms),
|
||
335.421 Instruktionen. Release-Messung auf diesem Rechner.
|
||
- Formatabgleich: **153/153 Opcodezeilen** einschließlich Operandentypen und
|
||
Bytebreiten sowie **9/9 Abschnittskennungen** gegen Writer/Reader abgeglichen.
|
||
- `openspec validate projektmodule-und-kompilat --strict`: bestanden.
|
||
- `git diff --check`: bestanden.
|
||
|
||
Die Abnahme ist eine lokale Code-/Testprüfung auf macOS; sie ist kein neuer
|
||
interaktiver Originalsystemvergleich und keine Windows-/Linux-Testmatrix.
|
||
|
||
## Reviewkorrekturen
|
||
|
||
Die ursprünglichen sieben Reviewproben bestehen unverändert, sowohl im
|
||
separaten Treiber als auch in der Workspace-Suite. Die dauerhafte Datei
|
||
`crates/tb-vm/tests/project_regressions.rs` ergänzt sie um neun Tests mit
|
||
verwandten Fällen. [review.md](review.md) ordnet die Korrekturen V1–V6 und
|
||
alle zusätzlich reproduzierten Abweichungen den Nachweisen zu.
|
||
|
||
`CommonArr` (`0x3B`) initialisiert gemeinsame Arrays einmal und prüft spätere
|
||
Laufzeitgrenzen auf Kompatibilität; vorab bekannte Konflikte meldet der
|
||
Linker an der ursprünglichen COMMON-Deklaration. Die neue Instruktion ist
|
||
in TBC 4 serialisiert, validiert und vollständig dokumentiert. Typ-Suffixe
|
||
bleiben in Debugger-Slotnamen erhalten. AST-Literale und sämtliche ausführbaren
|
||
Zweig-/Schleifenteile tragen ihre tatsächlichen Quellpositionen.
|