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

--cap-lints=warn are "ignored" in RUSTDOCFLAGS #67533

Closed
ignatenkobrain opened this issue Dec 20, 2019 · 3 comments · Fixed by #128780
Closed

--cap-lints=warn are "ignored" in RUSTDOCFLAGS #67533

ignatenkobrain opened this issue Dec 20, 2019 · 3 comments · Fixed by #128780
Labels
A-doctests Area: Documentation tests, run by rustdoc C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@ignatenkobrain
Copy link

Problem

I am trying to package async-std crates for Fedora and that includes running tests for them. I learned that they fail because #![feature(async_await)] is used. We are passing --cap-lints=warn in RUSTFLAGS, but that seems to be not enough. I have tried setting RUSTDOCFLAGS to pass this argument, but that does not seem to be respected.

   Doc-tests async-task
     Running `/usr/bin/rustdoc --edition=2018 --crate-type lib --test /home/brain/rpmbuild/BUILD/async-task-1.0.0/src/lib.rs --crate-name async_task -L dependency=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps -L dependency=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps --extern async_task=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps/libasync_task-02b10d3ab134b052.rlib --extern crossbeam=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps/libcrossbeam-94d09b2f1a7d16d7.rlib --extern crossbeam_utils=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps/libcrossbeam_utils-07a37c9338813562.rlib --extern futures=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps/libfutures-d20f84983f6edcd1.rlib --extern lazy_static=/home/brain/rpmbuild/BUILD/async-task-1.0.0/target/release/deps/liblazy_static-0209edcb3ceb1faa.rlib -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -Ccodegen-units=1 --cap-lints=warn`

running 4 tests
test src/task.rs - task::spawn (line 24) ... FAILED
test src/lib.rs -  (line 13) ... FAILED
test src/lib.rs -  (line 58) ... FAILED
test src/lib.rs -  (line 30) ... FAILED

failures:

---- src/task.rs - task::spawn (line 24) stdout ----
error: the feature `async_await` has been stable since 1.39.0 and no longer requires an attribute to enable
 --> src/task.rs:23:12
  |
3 | #![feature(async_await)]
  |            ^^^^^^^^^^^
  |
note: lint level defined here
 --> src/task.rs:21:27
  |
1 | #![deny(rust_2018_idioms, warnings)]
  |                           ^^^^^^^^
  = note: `#[deny(stable_features)]` implied by `#[deny(warnings)]`

error: aborting due to previous error

Steps

  1. Grab async-std tarball from crates.io
  2. Run doc-tests on it with rustc 1.39+
  3. Try to pass --cap-lints=warn in RUSTFLAGS and RUSTDOCFLAGS

Possible Solution(s)

I did not look into the code, but I believe it just does not get propagated somewhere.

Notes

Output of cargo version: cargo 1.39.0

This is happening on x86_64 on Fedora with its compiler, but I am pretty sure this will happen with rustup compiler too.

@ehuss ehuss transferred this issue from rust-lang/cargo Dec 22, 2019
@ehuss
Copy link
Contributor

ehuss commented Dec 22, 2019

Transferred to rust-lang/rust, as this seems to be an issue with rustdoc --test doesn't propagate --cap-lints to the tests.

@Alexendoo Alexendoo added A-doctests Area: Documentation tests, run by rustdoc C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jan 15, 2020
@decathorpe
Copy link

We are still getting bitten by this. Especially because some projects appear to apply stricter linting settings to their doctests / example code snippets in doc comments than they do in their actual code ...

@RalfJung
Copy link
Member

IMO, deny(warnings) checked-in to the repo is an anti-pattern. It's quite annoying when you use a slightly different version of the toolchain than CI and then can't even build the project -- adding new warnings is explicitly not a breaking change after all. So it'd be entirely reasonable to report bugs with these projects asking them to remove the deny(warnings) from the sources (and I've done this in the past).

That said, some projects will not follow best practices, so there should still be a way to deal with that. I'm not quite sure what happens here -- doesn't the rustc invoked by rustdoc get passed RUSTFLAGS? It seems like it does not, but then I wonder why that doesn't break a lot more often.

@bors bors closed this as completed in 472bbb9 Dec 21, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 21, 2024
Rollup merge of rust-lang#128780 - GuillaumeGomez:rustflags-doctests, r=rustdoc

Add `--doctest-compilation-args` option to add compilation flags to doctest compilation

Fixes rust-lang#67533.
Tracking issue: rust-lang#134172

It's been something I meant to take a look at for a long time and actually completely forgot... The idea is to allow to give more control over how doctests are compiled to users. To do so, this PR adds a new `--doctest-compilation-args` option which provides extra compilation flags.

r? `@notriddle`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-doctests Area: Documentation tests, run by rustdoc C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
5 participants