-
Notifications
You must be signed in to change notification settings - Fork 6k
Use flutter.js in the actual test harness. #47670
Use flutter.js in the actual test harness. #47670
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie or stuartmorgan on the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!). 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. |
|
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. |
|
Golden file changes are available for triage from new commit, Click here to view. |
ditman
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.
This looks good to me, but I have a feeling that this can be simplified a little bit without losing features. LMK what you think/do whatever you want from my feedback.
Also, golden opportunity of removing initializeEngine from the engine/initialization.dart, because AFAIK it's only used by the test harness of the engine anymore!
| class JsFlutterConfiguration { | ||
| external factory JsFlutterConfiguration(); | ||
| } |
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.
This class should handle the FlutterConfiguration coming from JS, so no need for this constructor here. We can just jsify as an empty Map to create a new JS Configuration object from Dart (tests).
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.
We should really avoid using jsify, and actually js_util in general. I think eventually the plan is for js_util to go away, and there is a js_util_unsafe library that should only be used in exceptional cases. Srujan mentioned that they probably at some point are going to have a constructor for JSObject that just creates an empty object, and then we can cast it. But even so, this seems a little more explicit and "correct" to me and I don't see a downside of exposing an anonymous constructor for the object.
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.
The thing is that there's nowhere in the production code (only tests) where this constructor is needed, I don't think there should be any ergonomic way of creating this from Dart :P, but my grief here is very minor :)
ditman
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.
Small comment about the debugOverrideJsConfiguration, which I think is not WAI (?)
| import { runTest } from "/test_dart2js.js"; | ||
| runTest({ | ||
| canvasKitBaseUrl: "/canvaskit/", | ||
| // Some of our tests rely on color emoji | ||
| useColorEmoji: true, | ||
| canvasKitVariant: "${getCanvasKitVariant()}", | ||
| }); |
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.
| return _configuration ??= FlutterConfiguration.legacy(_jsConfiguration); | ||
| } | ||
| FlutterConfiguration? _configuration; | ||
| FlutterConfiguration? _debugConfiguration; |
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.
Ahhh that's because _jsConfiguration is not available anymore (in dart2js mode, at least!).
I think the debugOverrideJsConfiguration method needs some extra love. The idea behind the method is that it lets you set and unset overrides for configuration that may be set by the test_runner, without breaking other tests.
I don't think the current implementation (even with debug) is doing that?
I think the debugOverrideJsConfiguration needs to:
_debugConfiguration = _configuration.clone()
// clone doesn't exist, but we need a way to clone the standard _configuration object :P
..setUserConfiguration(newJsConfig as JsFlutterConfiguration);So we end up with whatever is set by the runner (the value of _configuration) and then we apply the user overrides (if any?).
| _configuration = FlutterConfiguration() | ||
| ..setUserConfiguration(newJsConfig as JsFlutterConfiguration); | ||
| print('Overridden engine JS config to: ${newJsConfig.dartify()}'); | ||
| _debugConfiguration = configuration.withOverrides(newConfig); |
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.
| _debugConfiguration = configuration.withOverrides(newConfig); | |
| _debugConfiguration = _configuration.withOverrides(newConfig); |
Or do we want to allow to override the overridden values?
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.
No, configuration.withOverrides is correct. Whatever mechanism was used to configure the tests, we should use that as our base set. Right now dart2wasm tests still use window.flutterConfiguration and the JS tests use flutter.js and explicitly pass the config in, so we should support both.
ditman
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 with some questions, but nothing major.
|
auto label is removed for flutter/engine/47670, due to - The status or check suite Linux mac_unopt has failed. Please fix the issues identified (or deflake) before re-applying this label. |
…138456) flutter/engine@1347413...d7ca057 2023-11-15 [email protected] Use flutter.js in the actual test harness. (flutter/engine#47670) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC [email protected],[email protected],[email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Run the JS unit tests with flutter.js.
I am going to leave the dart2wasm tests doing the old
window.flutterConfigurationsetup for now, until I actually get dart2wasm/dart2js switching logic built into flutter.js itself.