idl-4.2 — Open Items
Aggregate of idl-4.2.en.md, generated by website/_tools/gen_open_items.py.
No new content: every entry appears there as an item with its evidence.
§7.2.5 Other Characters Recognized by IDL (Punctuation)
Status: partial — the operator ladder and # are covered one by one; no test covers all 28 characters of Table 7-7 or all five of Table 7-8. The iso-8859-1 letters of Table 7-2 are not probed either.
§7.2.6.2.2 Escape Sequences
Status: partial — the decimal and hexadecimal forms are covered in the lexer test, the \u/\U form only as an .idl fixture under tools/idlc/tests/idl-4.2-gaps/, not as a Rust test.
§7.4.1.3 Syntax (Productions 1–68)
Status: partial — the productions are recognised, but production 62 allows native_type as a member type spec too (<type_spec> ::+ <native_type> | …); struct S { native H; }; is not covered, parse_type_spec has no Native branch. The gap is measured in idl-4.2.gaps.md §A.
§7.4.1.4.4.2.2 Floating-Point Types
Status: partial — float and double are modelled and tested. long double is modelled as Float128; the arithmetic of a long double expression is refused (EvalError::LongDouble), own item.
§7.4.1.4.4.2.2 long double as IEEE double-extended
Status: blocked — Rust stable has no type f128 (rust-lang/rust#116909); lifted once f128 is available in Rust stable. Until then the constant evaluation refuses long double arithmetic with EvalError::LongDouble.
§7.4.1.4.4.6 Native Types
Status: partial — the declaration is covered, the use as a member type (struct S { native H; };) is not; see the item on §7.4.1.3.
§7.4.3.4.3.2.1 Inheritance Rules
Status: open — there is neither a diagnostic for a base interface named twice nor a transitive walk in the front end; the check inheritance_rules in crates/idl-lower/src/validate.rs applies only to TypeKind::Structure. The keyword virtual occurs nowhere in today’s tree. The flattening in crates/lang-rules happens per column, not in the front end.
§7.4.3.4.3.3.1 Operations
Status: partial — oneway and raises are tested. For the directions in/out/inout and for the context (…) clause there is no test that goes through the front end: the context clause is parsed and lowered (OperationNode::contexts), but no committed .idl file of the tree contains one, and ParamDirection is checked only in hand-built model tests.
§7.4.3.4.3.3.2 Attributes
Status: partial — readonly attribute and the derivation of the operations are covered; getraises and setraises are parsed and lowered (add_attribute_raises), but no test asserts anything about them. Only the fixture crates/idl-parse/tests/fixtures/spec_features/attr_raises.idl drives them through the pipeline, without a statement about the result.
§7.4.4.4 Multiple Inheritance and Ambiguity
Status: partial — the flattening over a diamond and the ambiguity report on the model level are covered. A front-end diagnostic for the ambiguity from two inherited, differently declared elements does not exist: inheritance_rules in crates/idl-lower/src/validate.rs knows only TypeKind::Structure as an inheritance carrier.
§7.4.4.4 Attribute and Operation with the Same Name
Status: open — code exists: one_namespace_per_scope (crates/idl-lower/src/lower.rs) collects attribute and operation names into one name list; no test creates an attribute and an operation of the same name in one interface.
§7.4.5.4.1.3.2 Initializers
Status: partial — no test checks that the factory declaration appears as an operation of the value type; the cited test only checks that it is not counted as a state member.
§7.4.6.4.1.3 Repository Id Conflict
Status: partial — the derivation is unique (one prefix, one typeid); a dedicated conflict test for two declarations with the same derived id does not exist. The present test checks the negative side (a reference to nothing is reported).
§7.4.6.4.4 Use of Native Types
Status: partial — the declaration is covered, the use as a member type spec (production 62) is not; see the item on §7.4.1.3.
§7.4.6.4.6 Context Expressions
Status: open — code exists: parsed and lowered (crates/idl-lower/src/lower.rs::operation, OperationNode::contexts); no test, no committed .idl file writes a context, the probe bb6-123-op-with-context in tools/idl-4.2-gap-scan/ has fixtures = 0.
§7.4.6.4.7 CORBA Module
Status: open — there is no module CORBA in any committed .idl file of the tree, no symbol in crates/idl-parse/src or crates/idl-lower/src and no probe. Object and ValueBase are reachable as built-in type names (§7.4.2.5), but not through a module whose content one could resolve.
§7.4.7.4.3 Value Inheritance Rules
Status: open — there is no check of these combinations. The only comparison of inheritance in the front end, inheritance_rules in crates/idl-lower/src/validate.rs, applies exclusively to TypeKind::Structure { base }; a Valuetype carries no base there.
§7.4.7.4.4 Custom Marshaling
Status: partial — the keyword custom is recognised and carried in the model as ValuetypeKind::Custom. The marshal/unmarshal operations are not recognised as such and not mapped onto skeleton operations; the test checks the variant, not the rule.
§7.4.7.4.5 Truncatable
Status: partial — truncatable is recorded as a modifier and evaluated in Table A.8. The truncation itself is not carried as such in crates/corba-codegen/src/skeleton.rs and has no test.
§7.4.7.4.6 Value Base
Status: partial — in the model ValueBase is present and reachable in every position; no language backend emits a form for it. The probe bb7-132-valuebase stands in expected.tsv for Rust and C on err (NoLanguageForm { construct: "ValueBase" }).
§7.4.8.4.2.1 Facets and §7.4.8.4.2.2 Receptacles
Status: partial — tested in the model and in the CCM rewrite. Both backends refuse the construct because the Object type carried by a port has no language form (NoLanguageForm { construct: "Object", language: "Rust" }, the same message for C); that is recorded in idl-4.2.gaps.md §C.2.
§7.4.9.4.1 Home Header
Status: partial — home with manages and the inheritance are covered. abstract home and home <identifier> for <scoped_name> are not: the keyword abstract reaches an expect(TokenKind::Interface) spot in crates/idl-parse/src/decl.rs::parse_interface, and the string home for does not occur in the tree.
§7.4.10.4.4.2 Object Root
Status: open — code exists: the form is parsed and lowered (crates/idl-parse/src/decl.rs::parse_port, ComponentRole::Facet with Ref::Broken); no test, the fixture crates/idl-parse/tests/fixtures/spec_features/ccm_components.idl is only checked for parse diagnostics. Both backends refuse the probe bb8-141-provides because Object has no language form.
§7.4.11.4.1.1 Port Type Declaration
Status: partial — present in the model and tested as InterfaceKind::PortType; Service::is_remote excludes PortType from every DDS-RPC binding. No language backend emits a port type binding (the probes bb11-173 and bb11-174 stand on err), and there is no test that asserts ComponentRole::PortTypeRole reaches the model.
§7.4.11.4.3 Connectors
Status: partial — connector is present in the model as InterfaceKind::Connector; the port/mirrorport members are parsed and lowered, but the CCM rewrite deliberately discards them (crates/ccm/src/transform.rs, line 255 ff., with the comment that the mapping through the port type is not §6 of this specification). No test asserts anything about ComponentRole::ConnectorRole.
§7.4.13.4.1 Void Content
Status: partial — the empty struct is accepted and the model carries it; the C backend refuses it (NoLanguageForm, C23 §6.7.2.1p8 leaves a structure without a named member undefined). Rust emits it.
§7.4.13.4.3.3 Duplicate @position
Status: open — check_bitmask_bounds (crates/idl-lower/src/complete.rs) checks @bit_bound, the number of values and the range of @position, but not that two @position values are equal. bitmask B { @position(1) A, @position(1) C }; is accepted; the later value overwrites the earlier one in the model.
§7.4.13.4.6 Ranges for all Integer Types (Table 7-26)
Status: partial — the table primitive_range mirrors exactly the columns of Table 7-26, but it is read only for case labels of a discriminator. The value range of a constant is not checked: value_disagrees_with compares only the form of the literal value, not its numeric value; const octet K = 300; and const int8 K = 200; go through.
§7.4.14.3 Rule (216) — template_type_spec as type_spec
Status: open — the clause is not checked as a form of its own. The path it opens (struct S { sequence<long> m; };) is not reachable in the parser (crates/idl-parse/src/type_spec.rs::parse_type_spec, crates/idl-parse/src/decl.rs::parse_member_list): parse_member requires a Declarator, and sequence<long> m; is read as a declarator. The tests of sequence parameters and a_sequence_member_carries_its_element_type check the template-module form, not the anonymous one.
§7.4.14.3 Rule (217) — array_declarator as declarator
Status: partial — the array dimensions are recognised at the declarator and assigned to it; that is tested through the typedef path. The anonymous form struct S { long arr[3]; }; has no test of its own.
§7.4.14.4 Nested Templates and >>
Status: partial — the nesting also works without whitespace (sequence<sequence<long>>), which the clause does not demand. The reverse case, the spelling with whitespace the spec demands (sequence<sequence<long> >), is touched by no test: the split branch is triggered only for the single >> token.
§7.4.15.4.1 Defining Annotations
Status: partial — the front end gives an annotation member with no default and no value the default of its type (XTypes 1.3 §7.3.1.2.5); IDL 4.2 requires a value here. The two specifications contradict each other; an issue draft for it is still missing.
§7.4.16 Dependency Lattice (Figure 7-2)
Status: open — there is no mapping of this lattice in today’s tree. crates/ast/src/profile/mod.rs::Profile is a flat enumeration of other specifications (Idl42Core, XTypes13, Corba33, Ros2, DdsXml, FlatData, Vendor), and there is no edge between the profiles. The only place the names of the building blocks occur is the prose in docs/idl-building-blocks.md.
§7.5.1 Ambiguity
Status: partial — the ambiguity report on the model level is covered and names every candidate. The spec example (§7.5.1: interface C: A, B with an attribute whose type is bound differently in both bases) is driven by no test.
§7.5.1 Visibility through Inheritance and Multiple Global Names
Status: open — there is no test that checks that an identifier inherited from a base is resolvable under two global names and that two paths to the same declaration are not a conflict. The flattening in crates/lang-rules is a language column, not a statement about the names.
§7.5.2 Introduction of an Identifier by Use
Status: open — there is no use support and no counter-check that transfers the name into the introducing scope. The survey under tools/idl-4.2-gap-scan/ lists the probe scope-7.5.2-introduced-ident with expect=reject, but measures ok; the two counter-probes scope-7.5.2-not-introduced-ok and scope-7.5.2-rooted-no-introduce pass today, rightly, but for the wrong reason, because the rule does not exist at all.
§7.5.2 Only the First Link of a Qualified Name is Introduced
Status: open — the same missing rule as in the item above. The probe scope-7.5.2-rooted-no-introduce passes, but measures nothing: without introduction tracking it cannot fail.
§7.5.3 Special Scoping Rules for Type Names
Status: partial — the bar holds for two openings of the same module and for the structure inheritance. The exception named in the clause, the reuse in a derived interface, is not tested as a positive case; the clause demands it.
§7.5.3 Potential Scope
Status: open — the notion potential scope has no counterpart in the tree. crates/idl-lower/src/scope.rs keeps a scope stack without a use count, hence without the bookkeeping from which the rule would follow. The positive note of the clause (redefinition after use in a module) has no test either.
§8.2.2 Rules for Using Standardized Annotations
Status: partial — no test checks the paragraph’s four requirements on a specification that uses a standardized annotation; the cited tests only check that unknown annotations are ignored and that the spelling counts.
§8.3.2.2 @must_understand Annotation
Status: partial — the flag reaches the member facet; the meaning of the flag (a middleware receiver that does not understand the extension must reject the message) is an XTypes requirement and is checked here only as a flag. That is the scope of clause 8.
§8.3.3.1 @default Annotation
Status: open — code exists: the annotation is in the builtin table, and the branch default in crates/idl-lower/src/annotation.rs::apply_one sets XTypesFacet::default_value. No test checks this field; crates/idl-lower/tests/annotations.rs has no case for it, the survey lists the probe ann-8.3.3.1-default as ok.
§8.3.3.2 @range Annotation
Status: partial — min/max are read and written into the facet; the condition max >= min is not checked and has no test. @range(5, 1) is accepted.
§8.3.6.2 @oneway Annotation
Status: partial — @oneway is in the builtin table, the survey lists the probe ann-8.3.6.2-oneway with ok. No Rust test writes @oneway into an .idl line and checks the facet (crates/ast/tests/node_space.rs::a_oneway_operation_is_flagged_and_a_normal_one_is_not checks the keyword form, not the annotation form). The secondary constraint of the clause — void return type and no out/inout parameters — is checked nowhere.
§9.1 Overview
Status: partial — the profile machinery exists and is checked totally by table, but it describes other specifications (XTypes13, Corba33, Ros2, DdsXml, FlatData, Vendor). The seven profiles of this clause are none of them.
§9.2.1 Plain CORBA Profile
Status: open — there is no mapping of this profile in the tree. Neither Profile nor IdlFeatures (formerly crates/idl/src/features/mod.rs, removed today) knows such a building block combination; the only place the name of the profile occurs is the prose in docs/idl-building-blocks.md.
§9.2.2 Minimum CORBA Profile
Status: open — as §9.2.1; no symbol, no test.
§9.2.3 CCM Profile
Status: partial — the building blocks of the profile are recognised and tested individually. The profile itself — a named, switchable combination — does not exist; there is no mechanism that switches the building blocks on and off together.
§9.2.4 CCM with Generic Interaction Support Profile
Status: partial — both additional building blocks are implemented and tested; the words GIS and Generic Interaction Support do not occur in the front end. As with §9.2.3 there is no profile switch.
§9.3.1 Plain DDS Profile
Status: open — no profile with this composition (crates/idl-parse/src/dialect.rs). The anonymous types are not tested (§7.4.14.3), and there is no check that separates the two building blocks together from a CORBA front end.
§9.3.2 Extensible DDS Profile
Status: partial — the XTypes part of the profile is modelled as Profile::XTypes13 and checked by table; the four annotation groups of this clause (General Purpose, Data Modeling, Data Implementation, Code Generation) do not exist as such, the annotations are a flat builtin table (§8.1).
§9.3.3 RPC over DDS Profile
Status: partial — the binding rule for interfaces is implemented and tested, including the list of languages that cannot render it completely. The profile as a switchable set of building blocks does not exist.
Annex A Consolidated Grammar (227 productions)
Status: partial — Annex A is enumerated in tools/idl-4.2-gap-scan/cases.tsv and the setpoints are pinned down in expected.tsv, not in a Rust test: 161 of the 227 productions carry a probe, 66 none. The measurement of these lines stands in idl-4.2.gaps.en.md; the tool run is tools/idl-4.2-gap-scan/scan.sh.
idl-4.2 — offene Punkte
Aggregat aus idl-4.2.md, erzeugt von website/_tools/gen_open_items.py.
Kein eigener Inhalt: jedes Item steht dort mit seinem Beleg.
§7.2.5 Other Characters Recognized by IDL (Punctuation)
Status: partial — die Operatorleiter und # sind einzeln belegt; ein Test über alle 28 Zeichen aus Tabelle 7-7 und alle fünf aus Tabelle 7-8 existiert nicht. Auch die iso-8859-1-Buchstaben aus Tabelle 7-2 sind nicht einzeln probiert.
§7.2.6.2.2 Escape Sequences
Status: partial — die dezimalen und hexadezimalen Formen sind im Lexer-Test belegt, die \u-/\U-Form nur als .idl-Fixture unter tools/idlc/tests/idl-4.2-gaps/, nicht als Rust-Test.
§7.4.1.3 Syntax (Produktionen 1–68)
Status: partial — die Produktionen sind erkannt, aber Produktion 62 erlaubt native_type auch als Member-Typ-Spec (<type_spec> ::+ <native_type> | …); struct S { native H; }; ist nicht abgedeckt, parse_type_spec hat keinen Native-Zweig. Die Lücke ist in idl-4.2.gaps.md §A gemessen.
§7.4.1.4.4.2.2 Floating-Point Types
Status: partial — float und double sind modelliert und getestet. long double ist als Float128 modelliert; die Arithmetik eines long double-Ausdrucks wird abgewiesen (EvalError::LongDouble), eigenes Item.
§7.4.1.4.4.2.2 long double als IEEE double-extended
Status: blocked — Rust stable hat keinen Typ f128 (rust-lang/rust#116909); aufgehoben, sobald f128 in Rust stable verfügbar ist. Bis dahin weist die Konstantenauswertung long double-Arithmetik mit EvalError::LongDouble ab.
§7.4.1.4.4.6 Native Types
Status: partial — die Deklaration ist belegt, die Verwendung als Member-Typ (struct S { native H; };) nicht; siehe das Item zu §7.4.1.3.
§7.4.3.4.3.2.1 Inheritance Rules
Status: open — es gibt weder eine Diagnose für ein doppelt genanntes Basis-Interface noch einen transitiven Gang im Frontend; der Abgleich inheritance_rules in crates/idl-lower/src/validate.rs gilt nur für TypeKind::Structure. Das Schlüsselwort virtual kommt im heutigen Baum nirgends vor. Die Abflachung in crates/lang-rules geschieht je Spalte, nicht im Frontend.
§7.4.3.4.3.3.1 Operations
Status: partial — oneway und raises sind getestet. Für die Richtungen in/out/inout und für die context (…)-Klausel gibt es keinen Test, der über das Frontend geht: die context-Klausel wird geparst und gelowert (OperationNode::contexts), aber keine committete .idl-Datei des Baums enthält eine, und ParamDirection wird nur in handgebauten Modell-Tests geprüft.
§7.4.3.4.3.3.2 Attributes
Status: partial — readonly attribute und die Ableitung der Operationen sind belegt; getraises und setraises werden geparst und gelowert (add_attribute_raises), aber kein Test behauptet etwas über sie. Nur die Fixture crates/idl-parse/tests/fixtures/spec_features/attr_raises.idl führt sie durch die Pipeline, ohne Aussage über ihr Ergebnis.
§7.4.4.4 Mehrfachvererbung und Mehrdeutigkeit
Status: partial — die Abflachung über einen Diamanten und die Mehrdeutigkeitsmeldung auf Modellebene sind belegt. Eine Diagnose im Frontend für die Ambiguität aus zwei vererbten, verschieden deklarierten Elementen gibt es nicht: inheritance_rules in crates/idl-lower/src/validate.rs kennt nur TypeKind::Structure als Vererbungsträger.
§7.4.4.4 Attribut und Operation mit demselben Namen
Status: open — Code vorhanden: one_namespace_per_scope (crates/idl-lower/src/lower.rs) sammelt Attribut- und Operationsnamen in eine Namensliste; kein Test lässt ein Attribut und eine Operation desselben Namens in einem Interface entstehen.
§7.4.5.4.1.3.2 Initializers
Status: partial — kein Test prüft, dass die factory-Deklaration als Operation des Value Type erscheint; der zitierte Test prüft nur, dass sie nicht als State-Member gezählt wird.
§7.4.6.4.1.3 Repository Id Conflict
Status: partial — die Herleitung ist eindeutig (ein Präfix, ein typeid); ein eigener Konflikt-Test für zwei Deklarationen mit derselben abgeleiteten Id existiert nicht. Der vorhandene Test prüft die negative Seite (ein Verweis auf nichts wird gemeldet).
§7.4.6.4.4 Use of Native Types
Status: partial — die Deklaration ist belegt, die Verwendung als Member-Typ-Spec (Produktion 62) nicht; siehe das Item zu §7.4.1.3.
§7.4.6.4.6 Context Expressions
Status: open — Code vorhanden: geparst und gelowert (crates/idl-lower/src/lower.rs::operation, OperationNode::contexts); kein Test, keine committete .idl-Datei schreibt ein context, die Probe bb6-123-op-with-context in tools/idl-4.2-gap-scan/ hat fixtures = 0.
§7.4.6.4.7 CORBA Module
Status: open — es gibt kein module CORBA in irgendeiner committeten .idl-Datei des Baums, kein Symbol in crates/idl-parse/src oder crates/idl-lower/src und keine Probe. Object und ValueBase sind als eingebaute Typnamen erreichbar (§7.4.2.5), aber nicht über ein Modul, dessen Inhalt man auflösen könnte.
§7.4.7.4.3 Value Inheritance Rules
Status: open — es gibt keine Prüfung dieser Kombinationen. Der einzige Abgleich von Vererbung im Frontend, inheritance_rules in crates/idl-lower/src/validate.rs, gilt ausschließlich für TypeKind::Structure { base }; ein Valuetype trägt dort keine Basis.
§7.4.7.4.4 Custom Marshaling
Status: partial — das Schlüsselwort custom wird erkannt und im Modell als ValuetypeKind::Custom geführt. Die Marshal-/Unmarshal- Operationen werden nicht als solche erkannt und nicht auf Skelett-Operationen abgebildet; der Test prüft die Variante, nicht die Regel.
§7.4.7.4.5 Truncatable
Status: partial — truncatable wird als Modifikator erfasst und in Tabelle A.8 ausgewertet. Das Abschneiden selbst wird in crates/corba-codegen/src/skeleton.rs nicht als solches geführt und hat keinen Test.
§7.4.7.4.6 Value Base
Status: partial — im Modell ist ValueBase vorhanden und an jeder Position erreichbar; kein Sprachbackend emittiert eine Form dafür. Die Probe bb7-132-valuebase steht in expected.tsv für Rust und C auf err (NoLanguageForm { construct: "ValueBase" }).
§7.4.8.4.2.1 Facets und §7.4.8.4.2.2 Receptacles
Status: partial — im Modell und in der CCM-Umschreibung getestet. Beide Backends lehnen das Konstrukt ab, weil der von einem Port getragene Object-Typ keine Sprachform hat (NoLanguageForm { construct: "Object", language: "Rust" }, dieselbe Meldung für C); das ist in idl-4.2.gaps.md §C.2 festgehalten.
§7.4.9.4.1 Home Header
Status: partial — home mit manages und die Vererbung sind abgedeckt. abstract home und home <identifier> for <scoped_name> sind es nicht: das Keyword abstract erreicht in crates/idl-parse/src/decl.rs::parse_interface eine expect(TokenKind::Interface)-Stelle, und die Zeichenkette home for kommt im Baum nicht vor.
§7.4.10.4.4.2 Object Root
Status: open — Code vorhanden: die Form wird geparst und gelowert (crates/idl-parse/src/decl.rs::parse_port, ComponentRole::Facet mit Ref::Broken); kein Test, die Fixture crates/idl-parse/tests/fixtures/spec_features/ccm_components.idl wird nur auf Parse-Diagnosen geprüft. Beide Backends lehnen die Probe bb8-141-provides ab, weil Object keine Sprachform hat.
§7.4.11.4.1.1 Port Type Declaration
Status: partial — im Modell vorhanden und als InterfaceKind::PortType getestet; Service::is_remote schliesst PortType von jeder DDS-RPC-Bindung aus. Kein Sprachbackend emittiert eine Porttyp-Bindung (die Proben bb11-173 und bb11-174 stehen auf err), und es gibt keinen Test, der behauptet, dass ComponentRole::PortTypeRole das Modell erreicht.
§7.4.11.4.3 Connectors
Status: partial — connector ist im Modell als InterfaceKind::Connector vorhanden; die port/mirrorport-Mitglieder werden geparst und gelowert, aber die CCM-Umschreibung verwirft sie bewusst (crates/ccm/src/transform.rs, Zeile 255 ff., mit dem Kommentar, die Zuordnung über den Porttyp sei nicht §6 dieser Specification). Kein Test behauptet etwas über ComponentRole::ConnectorRole.
§7.4.13.4.1 Void Content
Status: partial — der leere Struct wird akzeptiert und das Modell trägt ihn; das C-Backend weist ihn ab (NoLanguageForm, C23 §6.7.2.1p8 lässt eine Struktur ohne benanntes Mitglied undefiniert). Rust emittiert ihn.
§7.4.13.4.3.3 Doppelte @position
Status: open — check_bitmask_bounds (crates/idl-lower/src/complete.rs) prüft @bit_bound, die Anzahl der Werte und den Bereich von @position, aber nicht, dass zwei @position-Werte gleich sind. bitmask B { @position(1) A, @position(1) C }; wird akzeptiert; der spätere Wert überschreibt den früheren im Modell.
§7.4.13.4.6 Ranges for all Integer Types (Table 7-26)
Status: partial — die Tabelle primitive_range bildet genau die Spalten aus Tabelle 7-26 ab, wird aber nur für Case-Labels eines Diskriminators gelesen. Der Wertebereich einer Konstante wird nicht geprüft: value_disagrees_with vergleicht nur die Form des Literalwerts, nicht seinen Zahlwert; const octet K = 300; und const int8 K = 200; gehen durch.
§7.4.14.3 Rule (216) — template_type_spec als type_spec
Status: open — die Klausel ist nicht als eigene Form geprüft. Der Pfad, den sie öffnet (struct S { sequence<long> m; };), ist im Parser (crates/idl-parse/src/type_spec.rs::parse_type_spec, crates/idl-parse/src/decl.rs::parse_member_list) nicht erreichbar: parse_member verlangt einen Declarator, und sequence<long> m; wird als Deklarator gelesen. Die Tests zu Sequenz-Parametern und a_sequence_member_carries_its_element_type prüfen die Template-Modul-Form, nicht die anonyme.
§7.4.14.3 Rule (217) — array_declarator als declarator
Status: partial — die Array-Dimensionen werden am Deklarator erkannt und dem Deklarator zugeordnet; getestet ist das über den typedef-Weg. Die anonyme Form struct S { long arr[3]; }; hat keinen eigenen Test.
§7.4.14.4 Verschachtelte Templates und >>
Status: partial — die Verschachtelung funktioniert auch ohne Whitespace (sequence<sequence<long>>), was die Klausel nicht fordert. Der umgekehrte Fall, die vom Spec verlangte Schreibweise mit Whitespace (sequence<sequence<long> >), wird von keinem Test berührt: der Split-Zweig wird nur für das einzelne >>-Token ausgelöst.
§7.4.15.4.1 Defining Annotations
Status: partial — das Front-End gibt einem Annotationsmember ohne Default und ohne Wert den Default seines Typs (XTypes 1.3 §7.3.1.2.5); IDL 4.2 verlangt hier einen Wert. Die beiden Specs widersprechen sich; ein Issue-Entwurf dazu fehlt noch.
§7.4.16 Abhängigkeitsgitter (Figure 7-2)
Status: open — es gibt im heutigen Baum keine Abbildung dieses Gitters. crates/ast/src/profile/mod.rs::Profile ist eine flache Enumeration anderer Specificationen (Idl42Core, XTypes13, Corba33, Ros2, DdsXml, FlatData, Vendor), und zwischen den Profilen gibt es keine Kante. Der einzige Ort, an dem die Namen der Bausteine vorkommen, ist die Prosa in docs/idl-building-blocks.md.
§7.5.1 Mehrdeutigkeit
Status: partial — die Mehrdeutigkeitsmeldung auf Modellebene ist belegt und nennt alle Kandidaten. Das Spec-Beispiel (§7.5.1: interface C: A, B mit einem Attribut, dessen Typ in beiden Basen unterschiedlich belegt ist) wird von keinem Test getrieben.
§7.5.1 Sichtbarkeit durch Inheritance und mehrere globale Namen
Status: open — es gibt keinen Test, der prüft, dass ein aus einer Basis geerbter Bezeichner unter zwei globalen Namen auflösbar ist und dass zwei Wege zu derselben Deklaration kein Konflikt sind. Die Abflachung in crates/lang-rules ist eine Sprachspalte, keine Aussage über die Namen.
§7.5.2 Einführung eines Bezeichners durch Benutzung
Status: open — es gibt keine use-Unterstützung und keine Gegenprüfung, die den Namen in den einführenden Scope überträgt. Die Erhebung unter tools/idl-4.2-gap-scan/ führt die Probe scope-7.5.2-introduced-ident mit expect=reject, gemessen wird aber ok; die beiden Gegenproben scope-7.5.2-not-introduced-ok und scope-7.5.2-rooted-no-introduce gehen heute durch, richtig, aber aus dem falschen Grund, weil die Regel gar nicht existiert.
§7.5.2 Nur das erste Glied eines qualifizierten Namens wird eingeführt
Status: open — dieselbe fehlende Regel wie im Item darüber. Die Probe scope-7.5.2-rooted-no-introduce geht durch, misst aber nichts: ohne Einführungs-Tracking kann sie nicht fehlschlagen.
§7.5.3 Special Scoping Rules for Type Names
Status: partial — die Sperre gilt für zwei Öffnungen desselben Moduls und für die Strukturvererbung. Der in der Klausel genannte Ausnahmefall, die Wiederverwendung in einem abgeleiteten Interface, ist nicht als positiver Fall getestet; die Klausel fordert ihn.
§7.5.3 Potential Scope
Status: open — der Begriff Potential Scope hat im Baum keine Entsprechung. crates/idl-lower/src/scope.rs führt einen Scope-Stack ohne Verwendungszählung, also ohne die Buchführung, aus der die Regel folgen würde. Auch die positive Note der Klausel (Redefinition nach Benutzung in einem Modul) hat keinen Test.
§8.2.2 Rules for Using Standardized Annotations
Status: partial — kein Test prüft die vier Anforderungen des Absatzes an eine Spezifikation, die eine standardisierte Annotation verwendet; die zitierten Tests prüfen nur, dass unbekannte Annotationen ignoriert werden und dass die Schreibweise zählt.
§8.3.2.2 @must_understand Annotation
Status: partial — das Flag erreicht das Member-Facet; die Bedeutung des Flags (ein Middleware-Empfänger, der die Erweiterung nicht versteht, muss die Nachricht zurückweisen) ist eine XTypes-Anforderung und wird hier nur als Flag geprüft. Das ist der Umfang der Klausel 8.
§8.3.3.1 @default Annotation
Status: open — Code vorhanden: die Annotation steht in der Builtin-Tabelle, und der Zweig default in crates/idl-lower/src/annotation.rs::apply_one setzt XTypesFacet::default_value. Kein Test prüft dieses Feld; crates/idl-lower/tests/annotations.rs hat keinen Fall dafür, die Erhebung führt die Probe ann-8.3.3.1-default mit ok.
§8.3.3.2 @range Annotation
Status: partial — min/max werden gelesen und ins Facet geschrieben; die Bedingung max >= min wird nicht geprüft und hat keinen Test. @range(5, 1) wird akzeptiert.
§8.3.6.2 @oneway Annotation
Status: partial — @oneway ist in der Builtin-Tabelle, die Erhebung führt die Probe ann-8.3.6.2-oneway mit ok. Kein Rust-Test schreibt @oneway in eine .idl-Zeile und prüft das Facet (crates/ast/tests/node_space.rs::a_oneway_operation_is_flagged_and_a_normal_one_is_not prüft die Schlüsselwort-Form, nicht die Annotation-Form). Die Nebenspannung der Klausel — void-Rückgabetyp und keine out/inout-Parameter — wird nirgends geprüft.
§9.1 Overview
Status: partial — die Profilmechanik existiert und ist tabellarisch total geprüft, aber sie beschreibt andere Specificationen (XTypes13, Corba33, Ros2, DdsXml, FlatData, Vendor). Die sieben Profile dieser Klausel sind keine davon.
§9.2.1 Plain CORBA Profile
Status: open — es gibt keine Abbildung dieses Profils im Baum. Weder Profile noch IdlFeatures (früher crates/idl/src/features/mod.rs, heute entfernt) kennen eine solche Building-Block-Kombination; der einzige Ort, an dem der Name des Profils vorkommt, ist die Prosa in docs/idl-building-blocks.md.
§9.2.2 Minimum CORBA Profile
Status: open — wie §9.2.1; kein Symbol, kein Test.
§9.2.3 CCM Profile
Status: partial — die Bausteine des Profils sind einzeln erkannt und getestet. Das Profil selbst — eine benannte, schaltbare Kombination — gibt es nicht; es gibt keinen Mechanismus, der die Bausteine gemeinsam an- und abschaltet.
§9.2.4 CCM with Generic Interaction Support Profile
Status: partial — beide zusätzlichen Bausteine sind implementiert und getestet; die words GIS und Generic Interaction Support kommen im Frontend nicht vor. Wie bei §9.2.3 gibt es keinen Profilschalter.
§9.3.1 Plain DDS Profile
Status: open — kein Profil mit dieser Zusammensetzung (crates/idl-parse/src/dialect.rs). Die Anonymous Types sind nicht getestet (§7.4.14.3), und es gibt keine Prüfung, die die beiden Bausteine zusammen von einem CORBA-Frontend unterscheidet.
§9.3.2 Extensible DDS Profile
Status: partial — der XTypes-Anteil des Profils ist als Profile::XTypes13 modelliert und tabellarisch geprüft; die vier Annotations-Gruppen dieser Klausel (General Purpose, Data Modeling, Data Implementation, Code Generation) existieren als solche nicht, die Annotationen sind eine flache Builtin-Tabelle (§8.1).
§9.3.3 RPC over DDS Profile
Status: partial — die Binding-Regel für Interfaces ist implementiert und getestet, einschliesslich der Liste der Sprachen, die sie nicht vollständig abbilden können. Das Profil als schaltbare Bausteinmenge gibt es nicht.
Annex A Konsolidierte Grammatik (227 Produktionen)
Status: partial — Annex A ist in tools/idl-4.2-gap-scan/cases.tsv enumerate und die Sollwerte in expected.tsv festgeschrieben, nicht in einem Rust-Test: 161 der 227 Produktionen tragen eine Probe, 66 keine. Die Messung dieser Zeilen steht in idl-4.2.gaps.md; der Werkzeuglauf ist tools/idl-4.2-gap-scan/scan.sh.