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

metadata::filter_platform fails on !amd64 #9238

Closed
mwhudson opened this issue Mar 5, 2021 · 2 comments · Fixed by #9246
Closed

metadata::filter_platform fails on !amd64 #9238

mwhudson opened this issue Mar 5, 2021 · 2 comments · Fixed by #9246
Labels
A-testing-cargo-itself Area: cargo's tests C-bug Category: bug

Comments

@mwhudson
Copy link

mwhudson commented Mar 5, 2021

Problem
metadata::filter_platform fails on e.g. powerpc64le-linux-gnu

Steps

  1. install rustup
  2. rustup default stable
  3. git clone https://github.com/rust-lang/cargo
  4. cd cargo
  5. cargo test metadata::filter_platform

Possible Solution(s)

The failure is rather long (you can see it in https://launchpadlibrarian.net/526141668/buildlog_ubuntu-hirsute-amd64.cargo_0.51.0-0ubuntu1~ppa1_BUILDING.txt.gz) but the upshot is that /packages/2/dependencies/2 and /packages/2/dependencies/3 are the other way around from how the test expects (test expects alt-dep first, output has host-dep first).

Now, I'm no expert but I don't see anything in the code that guarantees the ordering of dependencies in the output. So I'm guessing this only passes on amd64 by chance. But I could be wrong!

Notes

Output of cargo version:

I observed this with c694096 and 0.51.0 built with "rustc 1.50.0 (cb75ad5db 2021-02-10)" on Ubuntu 20.04. I also saw the same test building cargo 0.51.0 on arm64, s390x and armhf with my rustc 1.50.0 packages.

@mwhudson mwhudson added the C-bug Category: bug label Mar 5, 2021
@ehuss
Copy link
Contributor

ehuss commented Mar 5, 2021

I don't see any errors in the linked build log, but I was able to verify with an aarch64 system.

Yea, it looks like the [target] tables are stored in sorted order. The test as written is assuming the host triple sorts alphabetically after wasm32, which is true for all x86* targets.

It'll be a bit tricky to fix, since there isn't any existing support code for ignoring the order of JSON arrays (I think it was removed in #8489). I'm guessing adding an option to ignore array order is an possibility. Another is to change that test to extract the JSON object, and selectively compare the important parts.

@ehuss ehuss added the A-testing-cargo-itself Area: cargo's tests label Mar 5, 2021
@mwhudson
Copy link
Author

mwhudson commented Mar 6, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testing-cargo-itself Area: cargo's tests C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants