[tool] Migrate off deprecated coverage parameters

[cbracken]

In #103771, we rolled
dependencies in Flutter, which triggered an update of package:coverage
to v1.3.1. The new version includes
dart-lang/coverage#370 in which two deprecations
landed:

• The Resolver default constructor was deprecated and replaced with
  the Resolver.create static factory method, which unfortunately
  happens to be async.
• The packagesPath parameter to HitMap.parseJson, which takes the
  path to the .packages file of the package for which coverage is to
  be collected, was deprecated. This parameter was replaced with
  packagePath in Deprecate --packages flag and add --package dart-lang/coverage#370 which
  was part of the overall deprecation of the .packages file in Dart
  itself [breaking change] discontinue .packages file dart-lang/sdk#48272. The overall goal
  being that end-user code shouldn't need to know about implementation
  details such as whether dependency information is stored in a
  .packages file or a package_info.json file, but rather use the
  package_config package to obtain the package metadata and perform
  other functions such as resolving its dependencies to filesystem
  paths. packagesPath was replaced by packagePath, which takes the path
  to the package directory itself. Internally, package:coverage then
  uses package_config to do the rest of the package/script URI
  resolution to filesystem paths.

This migrates off the deprecated packagesPath parameter to the
replacement packagePath paramter.

No test since this simply migrates off a deprecated parameter and onto its
replacement; the goal is to maintain identical behaviour.

Issue: #103830

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[flutter-dashboard]

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 on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on 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.

[cbracken]

/cc'ed to @xster since this seems very likely to require a tweak to our internal usage of the tool code in finalizeCollection in host_entrypoint.dart.

[jonahwilliams]

have you made a g3fix for google3?

[cbracken]

have you made a g3fix for google3?

I have not, mostly because I haven't seen this fail the google presubmit, though looking at the checks list now it doesn't appear it's in there. Is that expected? I thought it was meant to be run on each commit.

[cbracken]

I've manually kicked off a test in google3.

[christopherfujino]

have you made a g3fix for google3?

I have not, mostly because I haven't seen this fail the google presubmit, though looking at the checks list now it doesn't appear it's in there. Is that expected? I thought it was meant to be run on each commit.

The way it works is one googler has to approve before it starts testing.

[cbracken]

I did try clicking the "Test PR" button, but it seems to have created cr/452068967 but not actually kicked off a presubmit.

Will wait till someone reviews/approves and see what happens.

[jonahwilliams]

frob is for smoke testing changes that impact a large number of clients, though it may catch tooling changes. Changes to tooling APIs only impact the google3 specific tooling, so I would recommend using code search and finding the callsites to update.

[cbracken]

Based on writing most of the coverage collection in google3 for both Dart and Flutter, if there is a breakage, I'd expect it to be very widespread (i.e. anything with tests, or nothing at all).

[cbracken]

Confirmed: this breaks the entire world internally. Will get together a g3fix patch.

Sadly, it doesn't look like the g3fix button is available from the unapproved CLs page. Once someone reviews, I'll get back to this.

[jonahwilliams]

use the g3fix tab

[cbracken]

Create G3Fix Failed!
Bad state: generic::permission_denied: CL must have LGTM.

I wonder if we're spending more time discussing this than it would take to actually review the patch.

[jonahwilliams]

the g3fix CL has to be approved

[cbracken]

Attempting to create it returns that error.

[jonahwilliams]

no, the CL itself that has the google3 changes must be approved

[jonahwilliams]

LGTM (discussed offline)

[christopherfujino]

LGTM