-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Remove 'must not be null' comments from painting and rendering libraries. #134993
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove 'must not be null' comments from painting and rendering libraries. #134993
Conversation
…amework libraries (#134994) ## Description This removes all of the comments that are of the form "so-and-so must not be null" or "so-and-so must be non-null" from the cases where those values are defines as non-nullable values. This PR removes them from the library in the repo that don't have anything to do with the framework. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - #134984 - #134991 - #134992 - #134993 ## Tests - Documentation only change.
830b304 to
a93e4ed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something is odd about this PR, it seems to add the "must not be null" comment in a couple of places??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I messed up when I was splitting this out into a separate PR. Should be fixed now.
399e37a to
9b7b328
Compare
goderbauer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Manual roll Flutter from 8936504 to f92884c (48 revisions) Manual roll requested by [email protected] flutter/flutter@8936504...f92884c 2023-09-21 [email protected] Rename `debugProfilePlatformChannels` to a constant that works in release mode (flutter/flutter#134922) 2023-09-20 [email protected] Mark ReastaurationManager not disposed (flutter/flutter#134832) 2023-09-20 [email protected] cover more tests with leak tracing (flutter/flutter#134834) 2023-09-20 [email protected] Fix leak in hardware_keyboard_test.dart (flutter/flutter#134380) 2023-09-20 [email protected] Fix memory leak in _SelectableTextState (flutter/flutter#135049) 2023-09-20 [email protected] Roll Flutter Engine from 39c0f2ea1f53 to 89d864552acd (4 revisions) (flutter/flutter#135169) 2023-09-20 [email protected] [deps] Update package:web dependency. (flutter/flutter#135174) 2023-09-20 [email protected] finer grained logging of Chromium launch sequence (flutter/flutter#135078) 2023-09-20 [email protected] Upgrade AGP version in tracing_tests (flutter/flutter#134671) 2023-09-20 [email protected] Cover cupertino/form_section_test with leak tracing (flutter/flutter#135158) 2023-09-20 [email protected] Cover more test/widgets tests with leak tracking #7 (flutter/flutter#134943) 2023-09-20 [email protected] Enable strict-inference (flutter/flutter#135043) 2023-09-20 [email protected] Cover more test/widgets tests with leak tracking #10 (flutter/flutter#135143) 2023-09-20 [email protected] cover more tests with leak tracing (flutter/flutter#134833) 2023-09-20 [email protected] codeisn extension safe iOS framework (flutter/flutter#134966) 2023-09-20 [email protected] Roll Flutter Engine from 6f256257b79f to 55314d08d792 (2 revisions) (flutter/flutter#135151) 2023-09-20 [email protected] Remove 'must be non-null' and 'must not be null' comments in widgets library (flutter/flutter#134992) 2023-09-20 [email protected] Roll Flutter Engine from 5f82fc2f6f24 to 6f256257b79f (1 revision) (flutter/flutter#135147) 2023-09-20 [email protected] [Android] Add Java/AGP/Gradle incompatibility warning to `flutter create` (flutter/flutter#131444) 2023-09-20 [email protected] Roll Packages from d4e2454 to 51e74b9 (12 revisions) (flutter/flutter#135145) 2023-09-20 [email protected] Remove 'must not be null' comments from various libraries. (flutter/flutter#134984) 2023-09-20 [email protected] Roll Flutter Engine from 6535421b30d3 to 5f82fc2f6f24 (2 revisions) (flutter/flutter#135142) 2023-09-20 [email protected] Roll Flutter Engine from 67d4aaef3c7b to 6535421b30d3 (1 revision) (flutter/flutter#135139) 2023-09-20 [email protected] Cover more test/widgets tests with leak tracking #8 (flutter/flutter#135045) 2023-09-20 [email protected] Cover more test/widgets tests with leak tracking #9 (flutter/flutter#135054) 2023-09-20 [email protected] Roll Flutter Engine from 83b4df415bf3 to 67d4aaef3c7b (1 revision) (flutter/flutter#135128) 2023-09-20 [email protected] Roll Flutter Engine from df4e6c079682 to 83b4df415bf3 (2 revisions) (flutter/flutter#135102) 2023-09-20 [email protected] Roll Flutter Engine from 9c6b2500282b to df4e6c079682 (1 revision) (flutter/flutter#135101) 2023-09-20 [email protected] Roll Flutter Engine from 24f7ac38dfa2 to 9c6b2500282b (3 revisions) (flutter/flutter#135098) 2023-09-20 [email protected] Roll Flutter Engine from 36379b62bec8 to 24f7ac38dfa2 (2 revisions) (flutter/flutter#135096) 2023-09-20 [email protected] Roll Flutter Engine from 81b93fc4a2cc to 36379b62bec8 (2 revisions) (flutter/flutter#135095) 2023-09-20 [email protected] Roll Flutter Engine from 5a924a9017d7 to 81b93fc4a2cc (2 revisions) (flutter/flutter#135093) 2023-09-20 [email protected] Remove 'must be non-null' and 'must not be null' comments from material. (flutter/flutter#134991) 2023-09-20 [email protected] Unpin url launcher (remake) (flutter/flutter#134958) 2023-09-20 [email protected] Roll Flutter Engine from a7af55c56aa6 to 5a924a9017d7 (10 revisions) (flutter/flutter#135085) 2023-09-20 [email protected] Manual roll Flutter Engine from a7af55c56aa6 to 0d7db40c27fd (7 revisions) (flutter/flutter#135079) 2023-09-20 [email protected] Remove 'must not be null' comments from painting and rendering libraries. (flutter/flutter#134993) 2023-09-20 [email protected] cover more tests with leak tracking (flutter/flutter#134837) 2023-09-20 [email protected] [flutter roll] Revert "Native assets support for Linux" (flutter/flutter#135069) 2023-09-20 [email protected] Manual roll Flutter Engine from 10c480310926 to a7af55c56aa6 (4 revisions) (flutter/flutter#135071) 2023-09-19 [email protected] Retry Linux web tests 1 time on roll presubmit (flutter/flutter#135073) 2023-09-19 [email protected] [web] Encode AssetManifest.bin as JSON and use that on the web. (flutter/flutter#131382) 2023-09-19 [email protected] Specify suggested format in doc comment. (flutter/flutter#134887) 2023-09-19 [email protected] Manual roll Flutter Engine from 28f14e6eec4f to 10c480310926 (6 revisions) (flutter/flutter#135066) ...
…amework libraries (flutter#134994) ## Description This removes all of the comments that are of the form "so-and-so must not be null" or "so-and-so must be non-null" from the cases where those values are defines as non-nullable values. This PR removes them from the library in the repo that don't have anything to do with the framework. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - flutter#134984 - flutter#134991 - flutter#134992 - flutter#134993 ## Tests - Documentation only change.
…ies. (flutter#134993) ## Description This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values. This PR removes them from the painting and rendering libraries. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - flutter#134984 - flutter#134991 - flutter#134992 - flutter#134994 ## Tests - Documentation only change.
…al. (flutter#134991) ## Description This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values. This PR removes them from the material library. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - flutter#134984 - flutter#134992 - flutter#134993 - flutter#134994 ## Tests - Documentation only change.
…34984) ## Description This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values. This PR removes them from the animation, cupertino, foundation, gestures, semantics, and services libraries. Each of them only had a few, so I lumped them together. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - flutter#134991 - flutter#134992 - flutter#134993 - flutter#134994 ## Tests - Documentation only change.
…library (flutter#134992) ## Description This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values. This PR removes them from the widgets library. This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some. In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow. This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these). ## Related PRs - flutter#134984 - flutter#134991 - flutter#134993 - flutter#134994 ## Tests - Documentation only change.
Description
This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
This PR removes them from the painting and rendering libraries.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
Related PRs
Tests