Move the command-line analyzer into the main repository

[bwilkerson]

I believe that there are four steps in this process:

• 1. Copy the code from the old repository to the new repository.
• 2. Fix the build system to build from the new location rather than the old.
• 3. Move the issues from the old repository to the new repository.
• 4. Update dartlang docs to point to new README location.
• 5. Remove the old repository. Make the old repo read-only. (Follow-up: Make deprecated analyzer_cli repo "read-only". #25192.)

We should wait to start this until 1.13 has shipped. When a step is finished, please mark it and assign this issue to the person responsible for the next step (or me if you don't know who that is).

[pq]

@whesse, I thinking about this one:

[2] Fix the build system to build from the new location rather than the old.

Minimally, I expect we need to remove analyzer_cli from DEPS and update dartanalyzer in bin... Anything not obvious to consider? Will gclient sync complain when it leaves third_party? Anything we can do to make things go smoothest?

Thanks in advance!

[whesse]

I don't see any problems with that. When people first update after it is removed, gclient sync will tell them to remove the directory manually. They may well miss that, and leave it there. After that, it may keep putting links to it in the out/[modeArch]/packages directory, until it is removed manually. But that should not be a problem.

[pq]

Regarding

1. Move the issues from the old repository to the new repository.

@nex3 : I know you have a clever script to do bulk issue moves... Is that handy?

[nex3]

My script is very hacky, and right now those hacks are strongly oriented towards moving issues from the SDK repo to a different repo rather than the reverse. Since there are relatively few issues, it would probably be easier to use the non-bulk mover or just do it manually.

[pq]

Good deal. Thanks!

[pq]

cc @Sfshaza for the dartlang doc update. (Thanks in advance! :))