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

Regression in 1.26: cannot find function assert_test_result in module self::test #49942

Closed
pietroalbini opened this issue Apr 13, 2018 · 5 comments
Labels
C-bug Category: This is a bug. regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Milestone

Comments

@pietroalbini
Copy link
Member

Multiple crates are failing with the error cannot find function 'assert_test_result' in module 'self::test' .

@pietroalbini pietroalbini added I-nominated T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. C-bug Category: This is a bug. labels Apr 13, 2018
@pietroalbini pietroalbini added this to the 1.26 milestone Apr 13, 2018
@Mark-Simulacrum
Copy link
Member

This feels like a problem on our part, maybe related to some libsyntax or resolution related changes, cc @petrochenkov @alexcrichton...

@SimonSapin
Copy link
Contributor

This is probably due to using https://crates.io/crates/rustc-test/0.2.0 which has [lib] name = "test" and so ends being used by code generated rustc --test instead of of the standard library’s test crate. In retrospect this "clever hack" was obviously a mistake since it ends up relying on unstable implementation details of that crate.

https://crates.io/crates/rustc-test/0.3.0 fixes this (by not overloading the test crate name, it is imported as extern crate rustc_test; instead). Each crate listed above has already updated to 0.3 at least in their git repository (only some of them in the latest crates.io version). Some of the build logs use old crate versions.

I don’t know if there’s anything for the Rust project to do here other than maybe trying to patch that "hole" in the stability system. (Maybe by somehow having crates from the sysroot take priority over Cargo dependencies? Or reject conflicts? Make Cargo pass --extern to rustc for sysroot crates?)

@alexcrichton
Copy link
Member

Ah this is unfortunate, @SimonSapin's diagnosis sounds spot on. Ideally we never would have allowed this in the first place but I think at this point it's basically "this is technically out of our stability guarantees so not much we can do"

@SimonSapin
Copy link
Contributor

I think that just because I managed (more or less accidentally) to use on the Stable channel some features that were really unstable doesn’t mean that we should consider them de-facto stable.

@alexcrichton
Copy link
Member

This was discussed during libs triage and we've decided to close this as "wontfix"

@pietroalbini pietroalbini added this to Won't fix in 1.26 regressions Apr 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
No open projects
1.26 regressions
  
Won't fix
Development

No branches or pull requests

4 participants