Repository navigation
driver nnbd - #74856
driver nnbd#74856
Conversation
| // found in the LICENSE file. | ||
|
|
||
| // @dart = 2.8 | ||
|
|
There was a problem hiding this comment.
Here and in some of the other files as well below.
| /// | ||
| /// * [getWidgetDiagnostics], which gets the [DiagnosticsNode] of a [Widget]. | ||
| Future<Map<String, Object>> getRenderObjectDiagnostics( | ||
| Future<Map<String, dynamic>> getRenderObjectDiagnostics( |
There was a problem hiding this comment.
Over aggressive find and replace. I tried making more things not dynamic and they weren't ready to change. Changing back.
| /// Creates a SceneDisplayLagSummarizer given the timeline events. | ||
| SceneDisplayLagSummarizer(this.sceneDisplayLagEvents) { | ||
| for (final TimelineEvent event in sceneDisplayLagEvents) { | ||
| for (final TimelineEvent event in sceneDisplayLagEvents!) { |
There was a problem hiding this comment.
Why's the final field sceneDisplayLagEvents nullable in the first place then? Wouldn't this always crash when you instantiate SceneDisplayLagSummarizer(null)?
There was a problem hiding this comment.
Yes, updating this. I think we just were missing an assert there.. Making it non-null.
| /// This is parsed from "traceEvents" data within [json] and sorted by | ||
| /// timestamp. Anything without a valid timestamp is put in the beginning. | ||
| final List<TimelineEvent> events; | ||
| final List<TimelineEvent>? events; |
There was a problem hiding this comment.
It's surprising that this can be null. Can we document that? Or should it always be an (sometimes empty) list?
There was a problem hiding this comment.
Hmm. I'm pretty sure the method that parses this was written in an overly cautious way. I was going to not change it, but I'm realizing now that it can only return null if another thing thatisn't allowed to be null (json) was null. I'm going to change it.
There was a problem hiding this comment.
I was wrong.
This can be null if the trace events are null in the JSON. I'll document it for now.
There was a problem hiding this comment.
I think changing it to an empty list would be fine, but would like to do that separately from this migration in case anything depends on this behavior.
|
I didn't update the packages correctly - we'll need to get an updated version of Since the tool depends on quiver and dwds, it might be worth doing anyway to help unblock the tool. |
|
ok, it looks like we can use fake_async, which is migrated and isn't conflicting in this repo. |
| // found in the LICENSE file. | ||
|
|
||
| // @dart = 2.8 | ||
|
|
There was a problem hiding this comment.
Looks like it's still not fixed here :)
| // found in the LICENSE file. | ||
|
|
||
| // @dart = 2.8 | ||
|
|
| // found in the LICENSE file. | ||
|
|
||
| // @dart = 2.8 | ||
|
|
|
This pull request is not suitable for automatic merging in its current state.
|
|
This pull request is not suitable for automatic merging in its current state.
|
|
Windows flaked twice on me for things I'm pretty sure are unrelated to this patch (native crashes in Dart). Merged up to head and trying again... |
| args: serialized, | ||
| ).then<Map<String, dynamic>>((vms.Response value) => value.json); | ||
| response = await _warnIfSlow<Map<String, dynamic>>( | ||
| ).then<Map<String, dynamic>>((vms.Response value) => value.json!); |
There was a problem hiding this comment.
We are seeing stack traces in our build failures that come from the _warnIfSlow method following this when it evaluates the future. The error is that a Map<String, dynamic> can't be null, so I believe that ! operator on this line may be encountering a null value here and failing the NNBD assertion.
|
We're not going to consider cherry picks to stable and beta for null safe driver or integration test. We evaluated this when creating the release branch for flutter 2 and concluded that it was too risky. Null safe driver and integration test will be available in the next beta/stable release |
NNBD migration for flutter_driver.
I've spot checked this on one or two tests from the devicelab locally. If it goes red on devicelab we can revert.
I'll also see if I can get a FROB run, but this will require a g3fix to enable null safety for the package internally.
Fixes #74849