Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"dep-info invalid" when trying to compile Servo #8298

Closed
mikedilger opened this issue May 30, 2020 · 3 comments · Fixed by #8473
Closed

"dep-info invalid" when trying to compile Servo #8298

mikedilger opened this issue May 30, 2020 · 3 comments · Fixed by #8473
Assignees
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug

Comments

@mikedilger
Copy link

Problem

cargo check is giving me this output

error: dep-info invalid
note: this is an unexpected cargo internal error
note: we would appreciate a bug report: https://github.com/rust-lang/cargo/issues/
note: cargo 1.45.0-nightly (cb06cb269 2020-05-08)

Since it explicitly wants me to file a bug report, I am dutifully doing so.

Steps

For me, all I did was:

  1. Pull servo from https://github.com/servo/servo (master is currently at 14303bd651e248e6e7a73759d622658088f9ddf1)
  2. run 'cargo check'

That probably wont reproduce it for you because if it did, none of the Servo devs would be able to work, which probably isn't happening.

Possible Solution(s)

I suppose there might be data in my ~/.cargo from previous versions of cargo that just ain't playing nicely. But it is out of my depth to speculate on a solution.

Notes

Output of cargo version:
cargo 1.45.0-nightly (cb06cb2 2020-05-08)

My system is ArchLinux, amd64

@mikedilger mikedilger added the C-bug Category: bug label May 30, 2020
@mikedilger
Copy link
Author

I see dep-info is related to fingerprints which are in target directories. I had a target/ directory from June 20 2019, last time I played with servo. cargo clean fixed this.

I kept the old target directory in case anyone cares to pursue this.

@ehuss
Copy link
Contributor

ehuss commented May 31, 2020

Thanks for the report. I'm able to repro, so no worries about that.

There is an assumption that the fingerprint directories have the rustc version in the hash, and thus backwards incompatible changes to the fingerprint formats are automatically handled when upgrading the version of rust. However, not all fingerprint hashes include the rustc version in the hash. I'm rather surprised this is the first report of this, since around that time (mid June 2019) there was a backwards incompatible change made to the fingerprint format.

I'll take a look at a fix. Backwards incompatible changes are rare, but it definitely shouldn't barf on it.

@ehuss ehuss self-assigned this May 31, 2020
@ehuss ehuss added the A-rebuild-detection Area: rebuild detection and fingerprinting label May 31, 2020
@ehuss
Copy link
Contributor

ehuss commented May 31, 2020

Repro:

cargo new --lib foo
cd foo
echo "[lib]" >> Cargo.toml
echo 'crate-type = ["dylib"]' >> Cargo.toml
cargo +nightly-2019-05-14 build
cargo +nightly-2020-05-30 build   

@bors bors closed this as completed in 62123e4 Jul 9, 2020
@bors bors closed this as completed in #8473 Jul 9, 2020
ehuss pushed a commit to ehuss/cargo that referenced this issue Jul 15, 2020
Avoid colliding with older Cargo fingerprint changes

The fingerprint format Cargo stores changed recently in a way that
older Cargos cannot understand. Unfortunately though older Cargos are
colliding on some compilation units trying to read the new format and
they're bailing out. This commit fixes this issue by ensuring that the
location for fingerprint metadata is different in older Cargos and newer
Cargos.

Fingerprint metadata is always stored in a location with a hash in the
file name. This hash typically includes the hash of rustc's version
information itself, but for units which don't have a `Metadata` it's a
much simpler hash which is much more likely to collide with other
versions of Cargo. The fix in this commit is to extract the metadata
version that we're hashing to a constant, and then also hash it for
generating a filesystem location to house fingerprint data for a unit
that has no `Metadata`.

Closes rust-lang#8472
Closes rust-lang#8298
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants