[analysis_server] Offer "create constructor" fix for non-final uninitialized fields - #64032
[analysis_server] Offer "create constructor" fix for non-final uninitialized fields#64032hkarmoush wants to merge 2 commits into
Conversation
…ialized fields Non-nullable instance fields only ever got an "Add late" quick-fix, even though the same "create a constructor" fix already existed for their final-field sibling. Reusing that producer for non-final fields too closes the gap and, as a bonus, handles classes that mix final and non-final uninitialized fields in one shot instead of offering a fix that only covers half the class. The non-final case needed two guards the final-only version didn't: skip nullable fields (they're already valid without a constructor) and drop `const` from the generated Flutter widget constructor when a non-final field is involved, since `const` requires every field to be final. Fixes dart-lang#47389
|
Thank you for your contribution! This project uses Gerrit for code reviews. Your pull request has automatically been converted into a code review at: https://dart-review.googlesource.com/c/sdk/+/534805 Please wait for a developer to review your code review at the above link; you can speed up the review if you sign into Gerrit and manually add a reviewer that has recently worked on the relevant code. See CONTRIBUTING.md to learn how to upload changes to Gerrit directly. Additional commits pushed to this PR will update both the PR and the corresponding Gerrit CL. After the review is complete on the CL, your reviewer will merge the CL (automatically closing this PR). |
…d fields for const eligibility canBeConst only inspected the class's own field declarations, so a class with an inherited or mixed-in non-final field (making it ineligible for a const constructor) still got one generated for it. ClassElement.hasNonFinalField already walks the supertype and mixin chain, so use it instead when a ClassElement is available. Enum containers don't have this problem to begin with (enum instance fields must always be final), so canBeConst keeps the old check for that case.
|
It appears that copybara can't copy your latest changes to Gerrit because of a CLA related issue. Let us know if you need help resolving the issue. |
|
I flushed CLA check by forcing a rescan. |
3 participants
Fixes #47389
If you write
int a;with no initializer, analyzer only offers to fix it with "Add late". But if you writefinal int a;instead, you also get a "create a constructor for me" quick-fix — that option just never got extended to non-final fields, even though nothing about the underlying logic actually requiredfinal.This reuses the same constructor-generating producer for the non-final case. As a bonus, it also handles classes that mix final and non-final uninitialized fields in one shot — previously you'd only get a fix that covered the final ones.
Two things needed guarding since non-final fields behave differently from final ones:
int? b;) is already valid Dart without a constructor, so those are left alone.const, butconstrequires every field to be final — that gets dropped automatically when a non-final field is involved.Test plan
create_constructor_for_final_fields_test.dartcovering: a single non-final field, mixed final/non-final fields, private fields, late-field exclusion, nullable-non-final fields being left untouched, and the Flutter widget case (confirmingconstis correctly dropped).pkg/analysis_server/test/src/services/correction/fix/suite (4762 tests) passes with no regressions.dart format/dart analyzeclean.