Strict parsing tests: rust structural signatures #777

Existing coverage note: this language already has a handful of scattered regression tests in tests/core_engine/test_language_standards_strict.py -- the Rust half of test_thermodynamic_operator_collisions (bitwise_ops vs closures) -- covering specific historical bugs. That is NOT the same as this epic's full per-signature template (positive/negative case + ambiguity sweep + ReDoS sweep for every non-None signature), which this language has never received. Fold the existing tests' coverage into (not duplicated by) the new suite where they already cover a signature.

Part of #518.

Language: rust

• Lexical family: recursive_block
• Extensions: .rs, .rlib, .rmeta
• 51 of the baseline structural signatures are defined (non-None) for this language in gitgalaxy/standards/language_standards.py.

Reference

gitgalaxy/standards/how_to_add_a_language.md is the canonical doc for what each signature is supposed to capture/exclude, the 5 lexical parsing families, and (recently added) the AI/ML and literate-programming extension packs. Read the INCLUDES/EXCLUDES wording there for any signature before writing its test -- the one-line descriptions below are a quick-reference copy, not the full spec.

A rule being None here is not a gap

Only write tests for the checklist below. If a signature isn't in this language's rules dict, or is explicitly None, that's an intentional "doesn't apply to this language" per the doc's Strict Feature Parity rule (#4) -- don't invent a synthetic match for it just to have a test.

Lexical family note: This language's lexical family is recursive_block -- block comments can be safely nested inside one another; confirm the engine correctly tracks nesting depth rather than terminating at the first closing token.

Known ambiguity patterns to check for this language

• bitwise_ops vs closures: already found in Rust itself (|a| a + 1 miscounted as bitwise-OR) -- an isolated regression test (test_thermodynamic_operator_collisions) already exists; confirm it's absorbed into the full per-signature suite.
• explicit_casts vs pointers: already found in C (cast syntax overlapping pointer-asterisk repetition) -- check for the same overlap given Rust's as-cast syntax alongside its raw-pointer/reference syntax.
• func_start vs macros: already found in C++ (a multi-line #define spiral hallucinating a function match) -- check whether a run of macro_rules!/attribute-macro lines can fool func_start.

Checklist (this language's non-None structural signatures)

Phase 1: Logic Topology & Structure

• branch -- Control flow that forces a decision or jump: if, else, switch, for, while, catch, try, &&, ||, ternary.
• args -- Parameter blocks of functions, methods, and lambdas. Must safely step over type hints and generics without ReDoS.
• structural_boundaries -- Keywords defining structural boundaries and straight-line execution: var, return, class, import.
• func_start -- Exact syntax anchoring the start of an executable block of logic: method signatures, constructors.
• class_start -- The syntax defining an object-oriented class, struct, or record.

Phase 2: Safety & Execution Risk

• safety -- Defensive programming constructs that prevent crashes at runtime: try/catch, explicit null checks, guard.
• safety_bypasses -- Syntax that actively bypasses type safety, swallows errors, or relies on unpredictable state: force unwrapping (!), any, raw memory casting, linter bypasses (@ts-ignore).
• high_risk_execution -- Process-killing commands and catastrophic runtime vulnerabilities: eval, exec, process.exit.
• io -- Interaction with disk, network, or external systems: file reading/writing, HTTP clients, sockets.
• api -- Code exposed to the outside world. Captures explicit visibility markers (export, public) AND implicit architectural defaults for implicitly-public languages (Python, Fortran).
• state_mutation -- Reassignment of variables or modifying collections: let, mut, volatile, .push(), .set().
• dead_code -- Commented-out structural code and unused logic trails: // if (x), /* var y */.
• doc -- Structured documentation meant to be parsed by IDEs or generators: JSDoc, docstrings.
• test -- Assertions and unit testing framework keywords: describe, it, assert, expect.

Phase 3: Architecture & Domain Sensors

• concurrency -- Asynchronous logic and parallel execution: async, await, Promise, Thread.
• ui_framework -- DOM manipulation and UI components: HTML tags, React hooks.
• closures -- Anonymous functions, lambdas, inline callbacks: fat arrows (=>).
• globals -- Accessing global state, environment variables, or system registries: window., process.env.
• decorators -- Annotations applied to classes/methods: @Injectable, [Obsolete].
• generics -- Type parameters indicating generic abstractions: , List.
• comprehensions -- Collection iterators or inline looping: .map(, .filter(.
• scientific -- Math, data science, and complex rendering libraries: Math., numpy.
• reflection_metaprogramming -- Metaprogramming, reflection, and dynamic property assignment: Reflection, Proxy, .bind().
• import -- Dependency resolution and module loading (import, require, using), plus the paired capture-group rule that extracts the exact dependency path string for the dependency graph.
• ownership -- Authorship metadata: @author, Created by:.

Phase 4: Specialized Sub-systems

• planned_debt -- Annotated future work: TODO, WIP, STUB.
• fragile_debt -- Explicit admissions of fragile or dangerous logic: HACK, FIXME, XXX.
• spec_exposure -- Audit tags establishing traceability of intent: [SPEC-123], [audit].
• ssr_boundaries -- Server-Side Rendering computation boundaries: getServerSideProps.
• events -- Event-driven architecture signatures and message brokers: emit, EventEmitter, Kafka.
• dependency_injection -- Inversion of Control (IoC) injection markers: @Autowired, @Inject.
• macros -- Compiler pragmas or macro definitions that generate code at compile-time: #define, macro_rules!.
• pointers -- Explicit tracking of raw memory addressing and pointer dereferencing: *const, &mut, IntPtr.
• memory_alloc -- Explicit unmanaged memory allocations and raw heap manipulations: malloc, new.
• inline_asm -- Direct CPU architecture bridging: asm, asm!.

Phase 5: Resource Management & Stability

• telemetry -- Structured logging and observability frameworks.
• debug_prints -- Ad-hoc, temporary debug statements: print(, console.log(.
• explicit_casts -- Explicitly bypassing the compiler's type-checker: as String, (int), static_cast.
• panics_and_aborts -- Forcefully destroying the current execution context: throw, raise, panic!, abort().
• thread_sleeps -- Thread blocking or forced timeouts: sleep(, delay(.
• bitwise_ops -- Bitwise operations manipulating raw bytes.
• sync_locks -- Explicitly coordinating threaded logic to prevent race conditions.
• immutability_locks -- Explicitly locking data so it cannot be mutated: const, final, readonly.
• cleanup -- Explicitly destroying state or releasing resources: free(, dispose(), .close().
• encapsulation -- Explicitly hiding logic from the rest of the application: private, protected, internal.
• listeners -- Waiting to receive state from an external broadcast: on(, addEventListener, subscribe(.
• test_skip -- Bypassed tests or ignored verification specs: @ignore, test.skip(.

Phase 6: Hybrid Domain Sensors

• serialization_parsing -- JSON, XML, YAML parsing libraries.
• regex_execution -- Native regex evaluation commands.
• time_date_logic -- Time/date instantiation and math.
• ipc_rpc_bridges -- Inter-process or RPC bridging commands.

Test template

For each checked signature: (1) a positive-match test against its documented includes, capturing exact group text where applicable; (2) a negative-match test against its documented excludes; (3) any cross-rule ambiguity check flagged above; (4) a ReDoS immunity test (reuse assert_redos_immune from tests/core_engine/test_language_standards_strict.py) sized to this rule's actual quantifiers. Group multiple signatures that share the same simple pattern into one parametrized test rather than writing near-duplicates -- don't force one test per key if several are trivially similar for this language.

New tests land in tests/core_engine/test_language_standards_strict.py, the existing home for this style of test.