You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(compiler-core): reset pre and v-pre state when parsing starts - #16165
If a parse throws while inside a v-pre or <pre> element, the closing tag never runs, so inPre, inVPre and currentVPreBoundary stay set and the next template in the same process gets parsed as if it were still inside them. reset() now clears them, along with the tokenizer's inVPre.
Summary by CodeRabbit
Bug Fixes
Parsing now correctly handles directives, interpolations, and text whitespace after a previous parse fails, including failures involving duplicate attributes in preformatted content. This prevents stale parser state from affecting subsequent parses.
No actionable comments were generated in the recent review.
Walkthrough
The parser and tokenizer reset methods now clear preformatted-text state after parse errors. Added tests check that later parses process directives, interpolations, and whitespace normally.
Changes: Parse state recovery
Layer / File(s)
Summary
Reset preformatted state and verify subsequent parses packages/compiler-core/src/parser.ts, packages/compiler-core/src/tokenizer.ts, packages/compiler-core/__tests__/parse.spec.ts
Parser reset clears inPre, inVPre, and currentVPreBoundary. Tokenizer reset clears inVPre. Tests check that subsequent parses handle directives and interpolations, and condense whitespace, after duplicate-attribute errors.
The change addresses parser state leaking between templates after errors. No merge-blocking concern is identified; merge after normal checks pass.
Pre-merge checks: 5
Check name
Status
Explanation
Description Check
Check skipped - CodeRabbit’s high-level summary is enabled.
Title check
The title "fix(compiler-core): reset pre and v-pre state when parsing starts" matches the main change. The diff resets inPre, inVPre, and currentVPreBoundary in the parser and resets inVPre in the tok…
Linked Issues check
Directly linked issue #16163 requires that a parse error inside v-pre or <pre> not leave inVPre, inPre, currentVPreBoundary, or tokenizer inVPre set for later compiles. The diff covers thi…
Out of Scope Changes check
All changes relate to the linked issue #16163. The three reset() assignments in parser.ts clear parser state that leaks after an aborted v-pre or <pre> parse. The single line in tokenizer.ts…
Docstring Coverage
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Full details: Title check
Explanation
The title "fix(compiler-core): reset pre and v-pre state when parsing starts" matches the main change. The diff resets inPre, inVPre, and currentVPreBoundary in the parser and resets inVPre in the tokenizer before a parse. The linked objectives describe the same fix, so the title is fully related to the changeset.
Full details: Linked Issues check
Explanation
Directly linked issue #16163 requires that a parse error inside v-pre or <pre> not leave inVPre, inPre, currentVPreBoundary, or tokenizer inVPre set for later compiles. The diff covers this. In packages/compiler-core/src/parser.ts, reset() now sets inPre = 0, inVPre = false, and currentVPreBoundary = null. In packages/compiler-core/src/tokenizer.ts, Tokenizer.reset() now sets this.inVPre = false. The new tests in packages/compiler-core/__tests__/parse.spec.ts cover both reported cases. The first parses <div v-pre><a x x></a></div>, expects a throw, then expects <p v-if="ok">{{ x }}</p> to produce a DIRECTIVE prop and an INTERPOLATION child. The second parses <pre><a x x></a></pre> with isPreTag, expects a throw, then expects <div> a b </div> to condense to ' a b '. Limits of this evidence: the tests were not executed. The inspected file view was truncated, so I could not confirm the call site that invokes tokenizer.reset() on each parse. The issue text states that the parser and tokenizer reset() run before a parse, which supports the chain. No other requirement from #16163 is unmet.
Full details: Out of Scope Changes check
Explanation
All changes relate to the linked issue #16163. The three reset() assignments in parser.ts clear parser state that leaks after an aborted v-pre or <pre> parse. The single line in tokenizer.ts clears the tokenizer flag that the same leak affects. The additions to parse.spec.ts are regression tests for those two cases. No unrelated files or behavior changes appear in the whole-PR diff against the merge base. The diff shows no changes to exported declarations. Limits: the tests were not executed, and the truncated file view did not show every call site, so the link between Tokenizer.reset() and the parse entry point rests on the issue text.
Full details: Docstring Coverage
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 3 files.
Finishing TouchesGenerate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
File: No configuration file from this repository applied
Commit: Unavailable
Layers: defaults
Review profile: CHILL
Plan: Advanced
Run ID: 38aaf6a6-c72b-4363-8188-1e5e33460799
Commits
Reviewing files that changed from the base of the PR and between 8b479a8 and 25d8511.
Files selected for processing: 3
packages/compiler-core/__tests__/parse.spec.ts
packages/compiler-core/src/parser.ts
packages/compiler-core/src/tokenizer.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
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
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.
close #16163
If a parse throws while inside a
v-preor<pre>element, the closing tag never runs, soinPre,inVPreandcurrentVPreBoundarystay set and the next template in the same process gets parsed as if it were still inside them.reset()now clears them, along with the tokenizer'sinVPre.Summary by CodeRabbit