GraphBuildState: PackageDataValue: "lib" and "proc-macro" are not exhaustive crate types

[git-bruh]

Trying to generate the PackageGraph of a project fails when crate foo depends on another crate bar (say libadd), and bar's library name differs from it's project name (say libalias), and is set to only output just an rlib:

called `Result::unwrap()` on an `Err` value: PackageGraphConstructError("for package 'user 0.1.0 (path+file:///home/testuser/guppy-repro/user)': no dependencies found matching 'libalias'")

Reproducer: https://github.com/git-bruh/guppy-repro

This happens because the kind field in the library is set to rlib, while the PackageDataValue implementation only checks for lib and proc-macro: 820f7a1#diff-e795818085b4dedc9587c812ad15b0a312ff1f2542d461e5a4d61f9f4ddce199R437, so the libalias entry from cargo's metadata gets ignored:

...
    {
      "name": "libadd",
      "version": "0.1.0",
      "id": "libadd 0.1.0 (path+file:///home/testuser/guppy-repro/libadd)",
      "dependencies": [],
      "targets": [
        {
          "kind": [
            "rlib"
          ],
          "crate_types": [
            "rlib"
          ],
          "name": "libalias",
          "src_path": "/home/testuser/guppy-repro/libadd/src/lib.rs",
          "edition": "2021",
          "doc": true,
          "doctest": true,
          "test": true
        }
      ],
      "manifest_path": "/home/testuser/guppy-repro/libadd/Cargo.toml",
    },
...

Stumbled upon this indireclty when cargo nextest started mysteriously failing, narrowed it down the issue to this crate: https://github.com/nextest-rs/nextest/blob/cd5c9b3f2e880991d12d3abb38f78a429e0e24ff/cargo-nextest/src/dispatch.rs#L953

Not sure of the reason for filtering just on the basis of lib and proc-macro, so creating an issue rather than a direct PR

[sunshowers]

Thanks. This is fixed in #158.

[sunshowers]

This is part of the just-released cargo-nextest 0.9.63.

[git-bruh]

Thanks a lot for the quick follow up!

[Veetaha]

Hey @sunshowers I recommend you to yank the cargo-nextest 0.9.62 version in crates.io at least. I wasted some time debugging this because I wasn't pinning the version of cargo-nextest in the packer image that we use on CI, and it took me a while to figure out that my image used 0.9.62, while locally I had 0.9.63. To prevent other people from stumbling over this, it's better to yank 0.9.62

[sunshowers]

Hi @Veetaha -- sure I've yanked it, but note that that won't automatically update Docker and other similar images.

[hawkw]

This fix appears to have introduced a regression when a crate has binary dependencies. I have a broken build at https://github.com/tosc-rs/mnemos/actions/runs/7008859631/job/19067723666?pr=299#step:7:873 which worked with nextest v0.9.62, but now fails on v0.9.63 with:

error: error parsing Cargo metadata

Caused by:
  failed to construct package graph: for package 'manganese 0.1.0 (path+file:///home/runner/work/mnemos/mnemos/tools/manganese)': no dependencies found matching ''

I'm going to try to put together a minimal reproducing example, but for now, the Cargo.toml for the crate that nextest doesn't like is here.

[sunshowers]

Ah I definitely didn't consider binary artifacts since they're currently unstable :(

[sunshowers]

@hawkw #174 should address this, and I'll try getting it out within the next few days.

[hawkw]

@sunshowers lovely, thanks for the incredibly speedy fix!