Repository navigation
[feature-request] Improve mustCallSuper analysis #64062
Description
Dart version: Dart SDK version: 3.13.0 (stable) (Wed Aug 5 00:28:05 2026 -0700) on "macos_arm64"
Consider:
import 'package:meta/meta.dart';
void main() {
Implementation().dispose();
}
class Base {
@mustCallSuper
void dispose() {
print('disposed:base');
}
}
mixin Mixin {
@mustCallSuper
void dispose() {
print('disposed:mixin');
}
}
class Implementation extends Base with Mixin {
@override
void dispose() {
print('disposed:implementation');
super.dispose();
}
}This prints:
disposed:implementation
disposed:mixinSince Mixin overrides the base implementation, it's dispose isn't called. And because Mixin doesn't know about Base it can't call super.dispose().
However, because Base specifies mustCallSuper on dispose and since it isn't called in the disposal hierarchy I think there should be a warning on: class Implementation extends Base with Mixin {. Specifying Base's dispose isn't being called. Something, along the lines: 'Base.dispose()' is overridden and annotated as '@mustCallSuper', but it's never invoked.
However, if Mixin was defined as:
mixin Mixin on Base {
@override
@mustCallSuper
void dispose() {
print('disposed:mixin');
super.dispose();
}
}There'd be no warning.
Related: #53549
Activity
lrhn commentedon Aug 18, 2026
The #53549 issue was solved by changing the Flutter
mixin class, not by fixing the@mustCallSuperannotation behavior, so the problem probably still exists.My suggestion is to make it a warning if a mixin application has a concrete member overriding a concrete superclass member that is
@mustCallSuper, and that member is not a@mustCallSupermember of anyon-type of the mixin.(If the
@mustCallSuperis on anon-type of the mixin, then it should already be a warning if the mixin member doesn't callsuper.member().)It's not perfect. If the member is a non-
@mustCallSuperof anontype, the mixin member can contain asuper.member()invocation. An alternative is to scan the mixin member body for a super-invocation when it overrides a@mustCallSupermember that exists in itsontypes, but not as@mustCallSuper. (If the member is not in theontypes, then we know the mixin member cannot callsuper.member().)There are no plans to change how mixins work, this is only an issue with
@mustCallSuper.