Skip to content

[finding] symbol-anchors cannot resolve an override member — a true symbol anchor to one is reported unresolved-symbol, and the remedy is a weaker anchor #16821

Description

@os-musk

Filed unassigned and unlabelled, as an observation for triage, by the #16711 implementer. Grade deliberately not asserted.

Found while writing #16711's gate header: scripts/check-scripts-symbol-anchors.mjs refused the anchor packages/drivers/driver-turso/src/turso-driver.ts#initObjects, which names a real, live declaration in that file.

Measured, with a firing control

scripts/symbol-anchors.mjs#symbolResolutionClass is the shared resolver every anchor corpus registers against. Driven directly on synthetic sources, 56faa7b9c4:

declaration    plain method            —  initObjects(o) {}
declaration    async method            —  async initObjects(o) {}
declaration    protected async         —  protected async initObjects(o) {}
declaration    public async            —  public async initObjects(o) {}
declaration    private plain           —  private initObjects(o) {}
UNRESOLVED     override async          —  override async initObjects(o) {}
UNRESOLVED     override plain          —  override initObjects(o) {}
UNRESOLVED     protected override async
UNRESOLVED     CONTROL: a name that is NOT there

The last row is the negative control and the five declaration rows are the positive ones, so the four UNRESOLVED readings are a real refusal and not a silent instrument. ⇒ the matcher accepts async, public, protected and private before a method name and does not accept override.

Why this is worth a card rather than a shrug

It fails loudly, which is the good half — nothing goes silently green. The cost is in what an author does next.

Shape of a fix, not asserted as the decision

Adding override to the modifier set the matcher already accepts looks like a one-token change, but it belongs to whoever owns that resolver: the same matcher serves docs/adr/** and scripts/** corpora, so a widened accept set moves both censuses at once, and the maintainer ruling behind the shared resolver is explicit that a corpus joins by registration and there is to be no second implementation. Whether the accept set should instead be derived rather than enumerated is the question this card cannot answer for the owner.

⛔ Not folded into #16711's PR — that card is fenced to the driver packages plus its own new gate script, and #16711's PR works around this by anchoring the class instead. ⛔ Also unrelated to #16713, which is a different regex in a different script.

Repro, no build needed:

node -e "const m = await import('./scripts/symbol-anchors.mjs');
console.log(m.symbolResolutionClass('class A {\n  override async f(o) {}\n}', 'x.ts', 'f'));
console.log(m.symbolResolutionClass('class A {\n  async f(o) {}\n}', 'x.ts', 'f'));"

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions