• Uint8List appears to be no longer needed.
• The only reason foundation.dart was imported was for the annotations exported by the meta package.
• Instead of ignoring individual lint rules, all lint rules should be ignored, so that the generated code doesn't fail users' CI, when the code is out of their control.

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I followed [the version and CHANGELOG instructions], using [semantic versioning] and the [repository CHANGELOG style], or I have commented below to indicate which documented exception this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
• All existing and new tests are passing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the Dart code generator for Pigeon. The changes include:

• Modifying the generated ignore_for_file comments to use type=lint, which disables all lint rules for the generated files.
• Removing the import of Uint8List from dart:typed_data in generated files.
• Changing the source of annotations (e.g., @immutable) from the Flutter foundation library to the meta package.
  These generator changes are reflected in the updated example and test files. The package version in pubspec.yaml, CHANGELOG.md, and generator_tools.dart has been updated to 26.1.10.

• Instead of ignoring individual lint rules, all lint rules should be ignored, so that the generated code doesn't fail users' CI, when the code is out of their control.

We should make this something we can override internally for our own test generation; while we don't want to fail client analysis, we also don't want to introduce actual problems that lints would catch without our CI telling us. (E.g., if we leave out an await where we should have one, we absolutely want our CI to fail.)

That's a great idea! Is there one (or a few) cental spot where I could put a flag, for code generation "for/during tests"? Are there already tests that assert that new code doesn't have warnings or lints? Or is that mainly the checked-in code-generated files?

@tarrinneal can advise on the best place to put an option for this. As for tests, anything checked in is run through analyze in CI, and we also run analysis on code generated for package-level Dart unit tests, so that's where we would expect to catch issues. We could always add a new custom test step if needed though.

That's a great idea! Is there one (or a few) cental spot where I could put a flag, for code generation "for/during tests"? Are there already tests that assert that new code doesn't have warnings or lints? Or is that mainly the checked-in code-generated files?

I think just a simple bool for internal tests in the external PigeonOptions is fine, with a hidden command line param as well.

the pigeon_lib file has most of this code. The internal options class will need also need this added so it get's plumbed to all the generators.

Done. Thanks for the pointers!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.