Remove a dead member's overrides along with it

[PiotrRogulski]

Fixes #62.

An @override member is not a candidate, so removing only the member the finder reports left every override of it overriding nothing — override_on_non_overriding_member on code that analyzed cleanly before.

textDocument/implementation answers with every member overriding the one asked about, transitively and across files, so each dead member is asked once and its overrides are coupled to its removal. They stay out of the report, as coupled removals always have.

A member is left report-only, marked unsafe to auto-remove, when an override cannot be deleted: it is a declaring parameter of a primary constructor (deleting one changes the constructor signature at every call site), it is in a file the run did not scan, or it has references of its own.

Two more fixes came out of review:

• A field override is deleted as a declarator. Coupled removals arrived as whole-node spans, which for a declarator covers only its own text, so final int a = 1, b = 2; could not be touched safely. CoupledRemoval now carries the kind and full range of what it deletes, and the remover's existing declarator handling takes over: the statement goes whole when every declarator does, one declarator comes out with its comma when only some do. One declarator can now reach the remover twice — reported in its own right and coupled to the member it overrides — which threw a RangeError, so it is deduplicated.
• A field declarator reads its statement's metadata. A statement's doc comment, annotations and modifiers all sit on its first declarator, so b in @override final int a, b; reported none of its own and was checked where an @override member is skipped. It now reads the metadata of the declarator that opened the statement, which covers @pragma('vm:entry-point') the same way.

Verification

On the issue's repro, --remove deletes the member and both of its overrides, and dart analyze stays clean where it previously reported a dangling @override. The same holds for a three-level chain and for overrides in another file.

New fixture (example/lib/scenarios/overrides.dart + overrides_impl.dart) and nine tests cover: a transitive override, an override from another file, a plain body field, a declarator sharing its statement with another dead one and with a live one, the two report-only cases, a member called through the interface staying unreported, and the existing Animal.sound/Dog.sound pair in the default fixture. Two remover tests cover the duplicate declarator and the partial statement. --remove over the whole override scenario leaves dart analyze clean; published 0.5.0 leaves five errors on the same fixture.

On lichess-org/mobile (641 files, 13,043 declarations, -e 'lib/l10n/**'), where this was first hit: same 159 findings and same 13 report-only as before, 89 dead members asked about overrides, 2 coupled — EngineOpponent.displayName and MaiaWeightsService.downloading, each with its subclass implementation. flutter analyze after --remove goes from 18 issues to 16, the two removed being exactly the override_on_non_overriding_member warnings.

Cost

One textDocument/implementation per reported dead member, one textDocument/references per override found, and one textDocument/selectionRange per field override — findings are a small fraction of the declarations a run already queries. The lichess run above spent 0.5s on all 89 members.

🤖 Generated with Claude Code

https://claude.ai/code/session_012YuAi9rcyBRnHD6gyGBRqw

[Komoszek]

We could probably cut down most of the comments and we should update PR's description