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.
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):
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.xcarries 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 (samedart fixdead-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 theextendsclause 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 thethis.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.