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.