Skip to content

Conversation

@jesswrd
Copy link
Contributor

@jesswrd jesswrd commented Nov 26, 2025

Null safety checks removed here. Looks like the dart compiler needs the explicit assurance that _targetPubPackage is not null. Analyze fails upon re-adding the null safety checks here.

Assigned nullable field to local var.

Fixes flutter/flutter#179152

Pre-Review Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

  1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. 2 3

@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

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 re-adds null safety assertion operators (!) to ensure the Dart compiler can correctly infer non-nullability of a class field. The changes are correct given the context. I have provided one suggestion to refactor a section of the code to use a local variable, which is a more idiomatic way to help Dart's flow analysis and avoid a null assertion.

Future<PackageResult> runForPackage(RepositoryPackage package) async {
if (_targetPubPackage != null) {
return _runForPubDependency(package, _targetPubPackage);
return _runForPubDependency(package, _targetPubPackage!);

Choose a reason for hiding this comment

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

medium

While using ! is valid here because of the null check on the previous line, a more idiomatic and safer approach in Dart is to assign the nullable field to a local variable. This allows Dart's flow analysis to promote the variable to a non-nullable type within an if block, avoiding the need for a null assertion.

Consider refactoring this block to:

    final String? targetPubPackage = _targetPubPackage;
    if (targetPubPackage != null) {
      return _runForPubDependency(package, targetPubPackage);
    }

@jesswrd jesswrd requested review from reidbaker and removed request for reidbaker November 26, 2025 19:50
@reidbaker
Copy link
Contributor

@jesswrd I found that this was fixed with a dart pub get. You did the correct thing and I had a bad configuration.

@reidbaker reidbaker closed this Nov 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flutter packages tool errors when using flutter 3.38.3

2 participants