Skip to content

Stable or versioned ABI? #11821

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

Closed
SimonSapin opened this issue Jan 26, 2014 · 4 comments
Closed

Stable or versioned ABI? #11821

SimonSapin opened this issue Jan 26, 2014 · 4 comments

Comments

@SimonSapin
Copy link
Contributor

The details of what’s in a compiled crate file is highly dependent on the Rust version. Different Rust versions are often incompatible. Ensuring binary compatibility is probably premature for Rust right now, but we should at least improve error messages.

Would it make sense to store an ABI version number in compiled crates?

Scenario:

  • Have a crate A
  • Have a crate B with extern mod A and using stuff from A
  • Build them both
  • Work on something else for a few weeks
  • Upgrade the compiler
  • Rebuild B

Desired result:

It either Just Works, or fails with an error message like "A has an incompatible ABI and needs to be rebuilt."

Obtained result (sometimes):

  • Internal compiler error.
  • Time wasted to figure out what’s going on.
% RUST_LOG=rustc=1 make
rustc -L ../rust-encoding url.rs --out-dir .
task 'rustc' failed at 'lookup_item: id not found: 108293', /home/simon/projects/servo/src/compiler/rust/src/librustc/metadata/decoder.rs:92
error: internal compiler error: unexpected failure
This message reflects a bug in the Rust compiler. 
We would appreciate a bug report: https://github.com/mozilla/rust/wiki/HOWTO-submit-a-Rust-bug-report
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
task '<main>' failed at 'explicit failure', /home/simon/projects/servo/src/compiler/rust/src/librustc/lib.rs:440
Makefile:17: recipe for target 'liburl.dummy' failed
make: *** [liburl.dummy] Error 101
@sfackler
Copy link
Member

There is a metadata version here: https://github.com/mozilla/rust/blob/master/src/librustc/metadata/encoder.rs#L1850 but it seems to have never been incremented (!).

@huonw
Copy link
Member

huonw commented Jan 27, 2014

@sfackler isn't this error slightly different to metadata versions?

Without digging into it much, I think what may be happening is:

  • build library A with compiler X, which links it against X's libstd and the NodeIds (etc) from that library,
  • build library B with compiler Y, so the compiler is trying to find X's NodeIds inside Y's libstd but libstd has changed and so the NodeIds don't correspond to anything meaningful.
  • compilation fails with weird error messages.

I.e. this problem is due to the actual version of libstd, while metadata versions are the version number of the format itself.

@SimonSapin
Copy link
Contributor Author

Any talk of ABI or version number in the original message was only speculation on may part. The important point is that this kind of situation should give a better error message.

@huonw
Copy link
Member

huonw commented Aug 4, 2014

I believe this is a dupe of #12601 and thus fixed by #12533.

Closing.

@huonw huonw closed this as completed Aug 4, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 1, 2023
Extend `maybe_misused_cfg` lint over `cfg(test)`

Fixes rust-lang#11240.

One thought I had is that we could use the levenshtein distance (of 1) to ensure this is indeed `test` that was targeted. But maybe it's overkill, not sure.

changelog: [`maybe_misused_cfg`]: Extend lint over `cfg(test)`

r? `@blyxyas`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants