Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

`$safeNavigationMigration(...)` in an event listener reads template locals from the wrong context

Geschlossen
  • Stimmt etwas nicht?
#585 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #587 von @edbzn — gemerged

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
backend, compilers

Rechercherichtung

Start by reading remove_safe_navigation_migration and the name resolution phase that handles listener handlerOps; the issue identifies both as possible points where the local scope is lost. Compare listener compilation with the working property binding in a focused reproduction using the supplied template. Done when the listener reads the restored option_r2 value and a regression test covers template locals inside migrated listener expressions.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

When $safeNavigationMigration(expr) is used inside an event binding, OXC resolves template-local
variables in expr (@for items, @if … as x aliases, let- variables) against the listener's
ctx (ctx.option) instead of the local restored from the view (option_r2). The argument is
always undefined, so the expression evaluates to null.

Property bindings that use the same builtin compile correctly. The bug is specific to listener
handler ops.

Reproduction (@oxc-angular/[email protected], @oxc-angular/vite/api)

import { transformAngularFile } from '@oxc-angular/vite/api';

const src = `import { Component } from '@angular/core';
@Component({ selector: 'x-probe', template: \`
@for (option of options; track $index) {
  <button (click)="pick(option?.value); pick2($safeNavigationMigration(option?.value))"
          [title]="$safeNavigationMigration(option?.label)"></button>
}\` })
export class Probe { options: any[] = []; pick(v: any) {} pick2(v: any) {} }`;

const r = await transformAngularFile(src, '/tmp/probe.component.ts', {}, { templates: {}, styles: {} });
console.log(r.code);
Actual
i0.ɵɵlistener("click", function Probe_For_1_Template_button_click_0_listener() {
  const option_r2 = i0.ɵɵrestoreView(_r1).$implicit;
  const ctx_r2 = i0.ɵɵnextContext();
  ctx_r2.pick(((option_r2 == null) ? null : option_r2.value));          // correct
  return i0.ɵɵresetView(ctx_r2.pick2(((ctx.option == null) ? null : ctx.option.value))); // wrong: ctx.option
});
// update block, correct:
i0.ɵɵproperty("title", ((option_r3 == null) ? null : option_r3.label));
Expected (what ngc emits)

The listener should read option_r2 for both calls:
ctx_r2.pick2(((option_r2 == null) ? null : option_r2.value)).

Impact

Angular's ng update migration for the v22 safe-navigation change inserts $safeNavigationMigration
automatically. Any migrated listener such as (click)="select($safeNavigationMigration(item?.id))"
inside @for/@if as/*ngFor now passes null at runtime. There's no compile error. In our
monorepo this broke a shared select component (every dropdown emitted null) and profile
activation toggles, and failed 21 component tests across 4 projects that pass under
@analogjs/vite-plugin-angular / ngc. Rewriting the three affected bindings as x?.y ?? null
made all 21 pass under OXC.

Possible cause

remove_safe_navigation_migration iterates view.create and view.update. Angular's
unit.ops() also yields each listener's handlerOps. If the marker in handler ops isn't converted
before resolve_names, or is converted with a different scope, the argument's LexicalReads skip
the restored-view locals. Unverified, this is a guess from reading the phase source.

Environment

  • @oxc-angular/vite 0.0.41 (linux-x64-gnu binding)
  • Angular 22.2.0, Vite 7.3.6
Vorherrschende Sprache
Rust
Sterne
240
Forks
24
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
75

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/oxc-angular-compiler

Alle Issues in voidzero-dev/oxc-angular-compiler

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.