Skip to content

Migrate test/fixtures/context.dart to null-safety #1698

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

Merged
merged 9 commits into from
Jul 30, 2022

Conversation

elliette
Copy link
Contributor

No description provided.

@elliette elliette requested a review from annagrin July 22, 2022 00:01
Copy link
Contributor

@annagrin annagrin left a comment

Choose a reason for hiding this comment

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

Thanks Elliott, some small comments

CompilationMode compilationMode = CompilationMode.buildDaemon,
NullSafety nullSafety = NullSafety.weak,
NullSafety? nullSafety = NullSafety.weak,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can this be non-nullable with the default value of NullSafety.weak? I don't think we have a use for a null value in this case.

ResidentWebRunner get webRunner => _webRunner!;
late ResidentWebRunner? _webRunner;

// here
Copy link
Contributor

Choose a reason for hiding this comment

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

temp comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops, thanks!

late BuildDaemonClient? _daemonClient;

ResidentWebRunner get webRunner => _webRunner!;
late ResidentWebRunner? _webRunner;
Copy link
Contributor

Choose a reason for hiding this comment

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

We don't always have a web runner (only in frontend server mode), should this not be late?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

late Client? _client;

ExpressionCompilerService get ddcService => _ddcService!;
late ExpressionCompilerService? _ddcService;
Copy link
Contributor

Choose a reason for hiding this comment

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

We don't always have a ddc service (only in build runner mode with expression evaluation enabled), should this not be late?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done!

@@ -90,11 +113,11 @@ class TestContext {
/// TODO(annagrin): Currently setting sound null safety for frontend
/// server tests fails due to missing sound SDK JavaScript and maps.
/// Issue: https://github.com/dart-lang/webdev/issues/1591
NullSafety nullSafety;
NullSafety? nullSafety;
Copy link
Contributor

@annagrin annagrin Jul 25, 2022

Choose a reason for hiding this comment

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

I think this could be final non-nullable, with a default value of NullSafety.weak

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like this isn't used, therefore removed

}) async {
sdkConfigurationProvider ??= DefaultSdkConfigurationProvider();
urlEncoder = urlEncoder ?? (url) async => url;
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought we allow a null url encoder, does it fail? Maybe some of the null safety migration changes was too strict? Since we are testing all scenarios here, we need to either require the url encoder to be non-null everywhere or allow a null here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is the ResidentWebRunner requires a non-null UrlEncoder: https://github.com/dart-lang/webdev/blob/master/dwds/test/fixtures/context.dart#L268. For the frontend_server_???_tests, we aren't passing in a URL encoder so without this they fail. I could also explicitly pass in a url encoder from these tests. Wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Discussed offline, ResidentWebRunner should accept a null urlEncoder

Copy link
Contributor

@annagrin annagrin left a comment

Choose a reason for hiding this comment

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

LGTM with one change request (make logic for _daemonClient similar to other fields if possible)

@@ -402,7 +409,7 @@ class TestContext {
_entryContents.replaceAll('Hello World!', 'Gary is awesome!'));

// Wait for the build.
await daemonClient.buildResults.firstWhere((results) => results.results
await _daemonClient?.buildResults.firstWhere((results) => results.results
Copy link
Contributor

Choose a reason for hiding this comment

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

Can _daemonClient be null here? If it could, I'd presume the tests might not work as there are no build results, so we probably should fail in that case anyway.
Btw, I see that _daemonClient is treated differently than the other fields of TestContext (ie there is no getter that asserts that _daemonClient is non-null) - is there a reason for the difference?

TestServer get testServer => _testServer!;
TestServer? _testServer;

BuildDaemonClient? _daemonClient;
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be possible to make _daemonClient logic similar to other fields here?

@elliette elliette merged commit 6b93e27 into dart-lang:master Jul 30, 2022
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.

2 participants