fix(parser): report incomplete control-flow blocks like Angular

[ashley-hunter]

A control-flow block whose header is never completed compiled with no error, and the block and everything it swallowed were silently dropped from the template. Present in 0.0.40.

@Component({
  selector: 'x-cut',
  template: `
    <text>before</text>
    @if (on() {
      <text>inside</text>
    }
    <text>after</text>
  `,
})
export class Cut {
  on() { return true; }
}

gave errors: [], decls: 2 and only the first <text>. It now fails with Angular's error:

Incomplete block "if". If you meant to write the @ character, you should use the "@" HTML entity instead.

Root cause

The lexer already emitted IncompleteBlockOpen for these, as Angular's does, but the HTML parser had no case for the token and skipped it, along with the parameter that had swallowed the rest of the template. Same hole #529 closed for IncompleteLet.

Changes

• Parser. An incomplete block is reported over Angular's span, from the @ to the next token, and kept in the tree with no children. Port of Angular's _consumeIncompleteBlock. Covers unclosed parameters, a block with no {, and a bare @if.
• Position in errors. HTML parse errors reached the errors array as a bare message with labels: []. This applies to all of them, including the @let error from fix(parser): report incomplete @let declarations like Angular #529. They now carry a position:
  • Inline template: a label with file offsets, so the codeframe points at the @if, and helpMessage of /x/cut.ts:7:5. ComponentMetadata records the inline template's span for this.
  • templateUrl file: helpMessage of ./cut.html:2:3, and no label because the offsets belong to the HTML file.
  • Inline template written with escapes: line 2, column 1 of the template, because its offsets cannot be mapped to the source exactly.
• Vite plugin. It passed only message to this.error, so none of the above would be visible to plugin users. It now appends the help text for every error and warning.

Tests

• html_parser_test.rs: 30 cases whose expected errors (message, start, end) and trees are the output of @angular/compiler 22.2.1's HtmlParser, including the three incomplete-block cases in its html_parser_spec.ts. Angular's lexer spec cases were already ported. With the parser change reverted, 25 fail; the other five are the cases that must keep working (user@example.com, a lone @, well-formed blocks).
• template_parse_error_position_test.rs: 6 tests for the surfaced diagnostic through transform_angular_file and compile_template_to_js, for inline, escaped inline and templateUrl templates.
• transform.test.ts and plugin.test.ts: 4 JS tests, including the template above.

Differences from Angular left as they are

• Angular keeps trailing whitespace in a block parameter ("cond {\n"); this lexer trims it. Spans and errors match.
• When an incomplete block is nested in a well-formed one, the outer block is also reported as unclosed. Angular words that Unclosed block "if" with a span; this repo says Unclosed block "@if" with a zero-width one. That error predates this change.
• Angular splits a parameter at any ; outside a string, so @for (item of fn(a; b); track item) {x} is an error there but compiles here.

Verified

• cargo test --all-features --no-fail-fast: 3152 passed
• cargo fmt --all -- --check, cargo check --all-features: clean
• cargo run -p oxc_angular_conformance: 1264/1264, no snapshot diff
• pnpm test: 405 passed; pnpm check: clean; pnpm test:e2e: 37 passed
• pnpm --filter @oxc-angular/compare compare --fixtures: 980 fixtures, 0 mismatches, output byte-identical to main

Review round 1 (deep review, verified against vendored Angular 22.2.1)

Fixed on top of the PR head:

• ICU expansion cases swallowed block tokens. The case body loop skipped every token it didn't name, so {x, plural, =a {@if}} never produced the new "Incomplete block" diagnostic. Case bodies now parse through the same dispatch as everywhere else (Angular runs a full sub-TreeBuilder per case), and a block left open at the case's } reports "Unclosed block" like EOF does.
• Backtick wasn't a quote in block params. chars.isQuote includes it, so )/; inside a template literal like `;` no longer close or split the parameter.
• Lexer errors reported a (line, column) pair as the byte offset. HtmlTokenError now carries the real offset, so lexer-origin errors label the offending character instead of pointing near file start.
• HMR endpoints. compile_template_for_hmr reported with InSource on the component .ts path over templateUrl text; now Unknown like the other entry points that don't know where the template text lives. The vite HMR endpoint builds its failure via describeDiagnostic, so the file:line:column help reaches the invalidate message.
• templateUrl vs identical inline template. Origin inference used content equality, so when both existed with the same text, errors labelled the inline literal. templateUrl now wins when resources resolve, matching upstream precedence.

Documented at their sites, not fixed (all verified pre-existing at the PR base or untouched paths): is_block_start's identifier-boundary check, get_block_name's whitespace collapse, ; inside nested parens, silent IncompleteComponentOpen, unclosed-block drain order/spans, zero-width incomplete-@let span, pipeline warnings being dropped (FullCompilationResult has no diagnostics field; napi warnings: vec![]), partial-mode templates never parsed, and unresolvable template values producing no diagnostic.

Tests: cargo test --all-features: 3203 passed, 0 failed. cargo fmt --check, conformance 1264/1264, fixture compare 1089 fixtures 0 mismatches, pnpm test 441 passed.