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

liballoc doc tests are "silently" failing #52243

Closed
glandium opened this issue Jul 11, 2018 · 5 comments · Fixed by #68357
Closed

liballoc doc tests are "silently" failing #52243

glandium opened this issue Jul 11, 2018 · 5 comments · Fixed by #68357
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@glandium
Copy link
Contributor

I noticed this in the output running python x.py test locally:

   Doc-tests alloc
error: no global memory allocator found but one is required; link to std or add #[global_allocator] to a static item that implements the GlobalAlloc trait.

and that didn't make tests fail.

Cc: @SimonSapin

@glandium
Copy link
Contributor Author

Same with panic_unwind:

   Doc-tests panic_unwind
error: no global memory allocator found but one is required; link to std or add #[global_allocator] to a static item that implements the GlobalAlloc trait.

@SimonSapin
Copy link
Contributor

This error message is printed when running rustdoc --test src/liballoc/lib.rs […], but before running any test. The code printing it is in src/librustc_metadata/creader.rs. It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem.

So I think there are two issues:

  • rustdoc keeps doing its thing even though there are errors. It probably should call something like abort_if_errors on its rustc::session::Session instance at some point.
  • This error should not occur in the first place. One way to inhibit it would be to tell creader that we’re "compiling" an rlib (CrateTypeRlib) rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line:

crate_types: vec![config::CrateTypeDylib],

The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.

@estebank estebank added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jan 19, 2019
@RalfJung
Copy link
Member

Related: #54010

@jethrogb
Copy link
Contributor

jethrogb commented Jul 3, 2019

@rustbot modify labels: +T-rustdoc

@rustbot
Copy link
Collaborator

rustbot commented Jul 3, 2019

Error: Parsing label command in comment failed: ...ify labels|error: must have : or to as label starter at >| +T-rustdo...

Please let @rust-lang/release know if you're having trouble with this bot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants