feat: run the new grammar engine behind an experimental flag (#467 step 5)#472
Open
SJrX wants to merge 1 commit into
Open
feat: run the new grammar engine behind an experimental flag (#467 step 5)#472SJrX wants to merge 1 commit into
SJrX wants to merge 1 commit into
Conversation
…ep 5) Wires the list-of-successes engine into the actual InvalidValue inspection, gated behind an opt-in setting, so it can be exercised in the real IDE while the original SyntacticMatch/SemanticMatch path stays the default. - ExperimentalSettings: a project-level PersistentStateComponent with useGrammarParseEngine (separate storage from PodmanQuadletSettings); a checkbox is added to the shared "systemd Unit Files" settings page. - GrammarOptionValue.generateProblemDescriptors: when the flag is on, validate() via parse() and map ParseOutcome onto the same problem descriptors (SemanticError -> highlight the bad token + literal-replacement quickfixes; SyntaxError -> highlight from the furthest offset; Valid -> nothing). Flag off -> unchanged. - Safety for running on the highlighting thread, kept IntelliJ-free in the engine: validate() gains a pure step cap (fail-open to Valid) and an onStep callback; GrammarOptionValue passes ProgressManager::checkCanceled. - Test: GrammarParseEngineInspectionTest drives the AF inspection end-to-end with the flag on (valid -> 0, invalid -> 3) and resets the flag in tearDown so the shared light-test project doesn't leak the opt-in into other tests. Per discussion, the whole inspection suite is NOT dual-run; the engine is covered by ParseTest and this spot-checks the wiring + mapping. Known minor difference: the new engine's bad-token localization can differ slightly from the old engine for some grammars (e.g. a quickfix range), to be reconciled before the flag becomes default. Refs #467 #345 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Wires the new list-of-successes engine into the actual
InvalidValueinspection — but behind an opt-in flag, so it can be exercised in the real IDE while the originalSyntacticMatch/SemanticMatchpath stays the default for everyone else.Why a flag
Until now the new engine lived entirely beside the old one with unit tests. A flag (mirroring the existing Podman experimental toggle) turns the scary all-or-nothing migration into "flip it, try it, iterate," and lets the real inspection tests run against the new engine end-to-end — a much stronger correctness signal than parallel unit tests.
Changes
ExperimentalSettings— project-levelPersistentStateComponentwithuseGrammarParseEngine, its own storage (kept out ofPodmanQuadletSettings). A checkbox is added to the shared "systemd Unit Files" settings page.GrammarOptionValue— when the flag is on,generateProblemDescriptorsrunsvalidate()and mapsParseOutcomeonto the same problem descriptors as the old path:Valid→ nothing,SemanticError→ highlight the bad token + literal-replacement quickfixes,SyntaxError→ highlight from the furthest offset.Flag off → today's code, untouched.
validate()gains a pure step cap (fails open toValidrather than flag what it couldn't fully explore) and anonStepcallback;GrammarOptionValuepassesProgressManager::checkCanceled, so cancellation works without any IntelliJ type leaking into the grammar package.GrammarParseEngineInspectionTestdrives theRestrictAddressFamilies=inspection end-to-end with the flag on (valid → 0 highlights, invalid → 3), plus a flag-off sanity check. It resets the flag intearDownbecause the light-test project is shared across classes.Notes
ParseTest; this just proves the wiring +ParseOutcome→descriptor mapping.::tcpvs:tcp, in a CGroupSocketBind test when the flag leaked — now fixed viatearDown). Validity detection matches; only the highlighted range/quickfix offset can differ.Try it
./gradlew runIde, enable Settings → Tools → systemd Unit Files → "Use the new grammar engine for value validation (experimental)", and edit a.servicefile.Refs #467 #345
🤖 Generated with Claude Code