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.

Sign up for GitHub

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

Jump to bottom

Unexpected internal error when doing nightly build and then stable build #8472

Closed
mtkennerly opened this issue Jul 9, 2020 · 2 comments · Fixed by #8473
Closed

Unexpected internal error when doing nightly build and then stable build #8472

mtkennerly opened this issue Jul 9, 2020 · 2 comments · Fixed by #8473
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug regression-from-stable-to-nightly Regression in nightly that previously worked in stable.

Comments

@mtkennerly
Copy link

Problem

I had Rust stable 1.44.1 installed and working fine. I then added nightly and did a build with:


rustup toolchain install nightly --allow-downgrade
cargo +nightly run --release

which worked fine. Then I tried to build on stable again, and I got an error:

$ cargo run --release
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.44.1 (88ba85757 2020-06-11)

However, cargo run (without --release) still works.

Steps

Method A:

  1. cargo clean
  2. cargo run --release
  3. cargo +nightly run --release
  4. cargo run --release

Method B:

  1. cargo clean
  2. cargo +nightly run --release
  3. cargo run --release
  4. cargo +nightly run --release
    • This invocation only showed incremental build output, whereas the other invocations resulted in full builds:
  5. cargo run --release

Possible Solution(s)

Just a workaround, but cargo clean resolves the issue.

Notes

Output of cargo version:

cargo 1.44.1 (88ba85757 2020-06-11)
  • OS: Windows 10
  • Toolchains: stable-x86_64-pc-windows-msvc (default) and nightly-x86_64-pc-windows-msvc
@mtkennerly mtkennerly added the C-bug Category: bug label Jul 9, 2020
@ehuss
Copy link
Contributor

ehuss commented Jul 9, 2020 •
edited
Loading

Thanks for the report!

This is essentially the same as #8298, though triggered by a different change (#8421). The repro:

  1. Create a project with dylib or cdylib crate type.
  2. cargo +nightly-2020-07-06 build
  3. cargo +1.44.1 build

I should have remembered that case during review, since I had just been looking at #8298.

@ehuss ehuss added A-rebuild-detection Area: rebuild detection and fingerprinting regression-from-stable-to-nightly Regression in nightly that previously worked in stable. labels Jul 9, 2020
@alexcrichton alexcrichton mentioned this issue Jul 9, 2020
Merged
@alexcrichton
Copy link
Member

I've tried to fix this in #8473 by ensuring that the reason bin/rlib works works for dylib/cdylib as well.

bors added a commit that referenced this issue Jul 9, 2020
@bors
Auto merge of #8473 - alexcrichton:fix-fingerprint-loc, r=ehuss
62123e4 
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 #8472
Closes #8298
@bors bors closed this as completed in 15d4960 Jul 9, 2020
ehuss pushed a commit to ehuss/cargo that referenced this issue Jul 15, 2020
@bors @ehuss
Auto merge of rust-lang#8473 - alexcrichton:fix-fingerprint-loc, r=ehuss
c810ed0 
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
Assignees
No one assigned
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-bug Category: bug regression-from-stable-to-nightly Regression in nightly that previously worked in stable.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Avoid colliding with older Cargo fingerprint changes alexcrichton/cargo
3 participants
@ehuss @alexcrichton @mtkennerly