Migrating analyzer_plugin to null safety

[incendial]

Hi, are there any plans for migrating analyzer_plugin to null safety? Our package depends on it and we want to start migration too. I'd be happy to open a PR for analyzer_plugin null safety migration if it isn't already in the works.

[devoncarew]

Thanks for the inquiry; there aren't currently plans to migrate it to null safety (and no plans not to, it's just that getting package:analyzer null safe was a larger priority).

A contribution would be welcome; if you haven't contributed through the dart-lang/sdk process before, you'll want to take a look at https://github.com/dart-lang/sdk/blob/master/CONTRIBUTING.md.

[scheglov]

We are not working yet on migrating analyzed_plugin, but we would like to have it migrated. So, if you have time to do it, this is great. Send your PR :-)

As far as I can see, almost all dependencies of analyzer_plugin are migrated, and have null safe versions published. One exception is dart_style, which has dart-lang/dart_style#1000 waiting for now. I will ping it.

[incendial]

I have already started working on the migration (using dart_style from git for now). Thanks for pinging them!

Although all dependencies seems to have null safe version, I have a problem with resolving both analyzer package direct dependency and through analyzer_utilities path override (path: ../analyzer_utilities). Never faced that issue before. Are there some command to resolve those type of issues or I just simply missing something?

[scheglov]

I have not tried exactly this, but you might need to use dependency overrides while working on this.

[incendial]

Oh, will try, thanks!

[incendial]

So yeah, I was doing it wrong and there is no need to call pub get inside a package.

I have two main questions:

1. Some classes used from the analyzer has fields that marked as non-nullable, but have old comments that suggest that they might be. Is it intensional or a mistake?
2. If I understood it correctly, protocol is generated from the html spec. Right now I have migrated those files by hand just to make sure that all tests pass. Do I need to migrate the generating tool (it seems like a harder task for now)? Will it also require analyzer_server and analyzer_server_client migrations?

I actually don't know if it's the right place to ask questions. If it's not, do you have a place where I can ask them?

[scheglov]

Ask any question here.

If there are any fields that have non-nullable type, but the comment says that they are nullable, please tell us about these fields. This most probably means that I did not update the comment.

It is fine if the generating tool looks too complicated for you, I can do this portion a bit later.

[incendial]

Thanks for the quick response!

Three places so far: first, second, third.

As for generating tool - I will take a look at it once more, but if I decide to leave it, should I revert changes to generated files? And it seems that migration is kinda huge (like ~85 changed files or so). How can I help you to review it (I can split it to a commit per file or group several files to a commit)?

[bwilkerson]

Do I need to migrate the generating tool (it seems like a harder task for now)?

If you mean migrating the code in the generator, then we ought to be able to do that separately. If you mean update the generator to produce null safe code, that might be necessary, even if it's just to add a // @dart= comment. I know that for the analysis_server package we have a test to ensure that we never forget to run the generator, and I think we did the same for the analyzer_plugin package. If we did, and if you hand-edit the generated code, then the test will fail.

Will it also require analyzer_server and analyzer_server_client migrations?

No. Those packages depend on the analyzer_plugin package, not the other way around.

[incendial]

If you mean update the generator to produce null safe code

Yeah, I meant produced code. But won't a // @dart= comment actually still block external packages (that depend on the analyzer_plugin) from null safety migration?

No. Those packages depend on the analyzer_plugin package, not the other way around.

Oh, thats great.

[scheglov]

Thank you, I will update these comments.
https://dart-review.googlesource.com/c/sdk/+/191481

Whatever is easier for you - if you have already done migrating the generated code, keep it.
Then me, or someone else, can update the generator to produce this or similar migrated code.

The generator itself is not a production code, so it will not prevent tests or clients from being null safe.

[bwilkerson]

But won't a // @dart= comment actually still block external packages (that depends on the analyzer_plugin) from null safety migration?

It shouldn't prevent it. The semantics of writing null safe code that depends on un-migrated code are well defined, and it shouldn't be a requirement to migrate all dependent packages first, but it is strongly advised for two reasons:

• waiting to migrate means that your code won't be broken by unforeseen changes to the packages you depend on when they're migrated, and
• depending on un-migrated code means that the VM can't assume soundness when running your code, which leads to less efficient execution performance.

So I think it would be reasonable to update the generator to generate those comments and then let someone else update the generator and regenerate the code before we publish the package.

Then me, or someone else, can update the generator to produce this or similar migrated code.

@scheglov Won't pkg/analyzer_plugin/tool/spec/check_all_test.dart fail?

[scheglov]

Yes, the check for generator will fail, we would have to disable it for a short time while we are working on migrating the generator.

[incendial]

Thank you, I will update these comments.

Great, I will remove null checks for those cases then.

It shouldn't prevent it. The semantics of writing null safe code that depends on un-migrated code are well defined, and it shouldn't be a requirement to migrate all dependent packages first, but it is strongly advised for two reasons:

• waiting to migrate means that your code won't be broken by unforeseen changes to the packages you depend on when they're migrated, and
• depending on un-migrated code means that the VM can't assume soundness when running your code, which leads to less efficient execution performance.

Oh, thanks for clarifying that. Am I correct, that if we assume that users of the analyzer_plugin are usually tools and used as dev dependencies which means that second statement about VM will not affect package prod build, only dev?

Here is the PR link https://dart-review.googlesource.com/c/sdk/+/191622

[incendial]

Should I disable checks for generator by myself? And do I need to update package version in pubspec? And is it intentional that generate_files files are a bit different, like here for server and here for plugin?

[incendial]

Could you please help with the next step after getting LGTM for the CL?

[scheglov]

Null safe analyzer_plugin 0.5.0 was published.

[incendial]

Thank you very much for helping me with the CL!

[bwilkerson]

Thanks for doing all the work to migrate it!

[incendial]

Hi, it seems that there is a small problem with null safety migration.

And as I can see, it was already fixed in main branch. Do you have a release date for that fix?

If it's more appropriate, I can create a separate issue for that.

[bwilkerson]

@scheglov

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/194542

[scheglov]

Published and landed.

[incendial]

Thank you! Works like a charm.