Skip to content

Pure consumer whose only link is a bare super.x parameter misses the syntactic probe gate #108

Description

@nank1ro

Problem

The last silent-miss in the pure-consumer family (documented as a residual gap in 3.0.0-dev.4's CHANGELOG and SPEC §2, follow-up to #106/#107):

// base_repository.dart
class BaseRepository {
  BaseRepository(this.authRepository);
  final AuthRepository authRepository;   // typed here, in the base class
}

// customers_repository.dart — annotation-free pure consumer
import 'base_repository.dart';

class CustomersRepository extends BaseRepository {
  CustomersRepository(super.authRepository);   // bare super param — no type text in this file

  bool hasSession() => authRepository.session != null;   // silently un-lowered
}

The probe gate that decides whether an annotation-free file enters the pipeline is syntactic: it seeds candidate names from the declared types it can literally see. A bare super.x carries no type annotation; only the resolved element model knows it — but resolution happens only after a file enters the pipeline. The resolved-path seeding from #107 therefore never gets a chance: the file takes the verbatim passthrough and the read stays un-lowered (same dart fix dead-code hazard as #106, on a much rarer shape).

Escape hatch today: explicitly type the super param (CustomersRepository(AuthRepository super.authRepository);) — supported since #105.

Candidate fix (stays syntactic)

When the probe sees a bare super.x, it already knows the superclass simple name from the extends clause and already walks the file's imports. Locate the superclass declaration syntactically (current unit or imports, honoring the existing shadowing/combinator rules) and seed from the matched super-constructor parameter's declared type — falling back to the superclass's same-named instance field's type for the this.x-style base pattern. Constructor matching must handle named vs positional params and the initializer list's target constructor (unnamed default); when matching is ambiguous, seed conservatively (all candidate types from that superclass constructor/fields — over-seeding a name is harmless by design) rather than silently skipping.

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

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions