Repository navigation
[pigeon] Remove remaining dart:mirrors usage #190228
Description
We still have a couple of minor uses of dart:mirrors, which we should try to eliminate since the bulk of Pigeon hasn't used mirrors in a long time:
- an
isVoidfunction in generator_tools.dart, which AFAICT isn't used anywhere and can just be removed - code in
runWithOptions, the library entry point that almost nobody uses AFAIK, to find a method calledconfigurePigeonand execute it. That seems to be a vestige of when that's how Pigeon configuration worked, instead of the annotation system we have now (https://pub.dev/packages/pigeon/changelog#030). Presumably the library call should be working the new way as well, not using the old method? Or if it has to be a method, we should probably make the client pass it in.
Activity
theprantadutta commentedon Oct 2, 2026
I'd like to pick this up. I checked both uses on current
main:isVoid(TypeMirror)ingenerator_tools.darthas no callers anywhere in the package (theisVoidused throughout the generators is the unrelatedTypeDeclaration.isVoidgetter inast.dart), so it can just go._executeConfigurePigeonis the only otherdart:mirrorsuser. It's called unconditionally at the start ofrunWithOptionsand walks every loaded library looking for a top-levelconfigurePigeon(PigeonOptions). Nothing intest/,example/orplatform_tests/defines one, so it's currently untested, and as you say it predates the@ConfigurePigeonannotation from 0.3.0.CONTRIBUTING.mdalso still says "This is howdart:mirrorsgets access to the supplied Pigeon file."With both gone,
dart:mirrorsdisappears from the package entirely (andCONTRIBUTING.mdgets corrected).The one decision I'd want from you is what happens to the hook:
runWithOptionscallers already pass a fully-formedPigeonOptions, so mutating it beforehand is the natural replacement. Technically breaking for anyone relying on the reflection lookup.void Function(PigeonOptions)? configureparameter onrunWithOptions— so nothing needs reflection.I'd lean towards (1) given how little it's likely used, with a CHANGELOG note — but I'm happy to do either, and to follow your call on the version bump if you treat it as breaking.
I'm at the open-PR limit in flutter/packages at the moment, so this would start as a draft.