rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.36k stars 12.72k forks source link

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

Open ignatenkobrain opened 4 years ago

ignatenkobrain commented 4 years ago

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 commented 4 years ago

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

decathorpe commented 7 months ago

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 commented 1 month ago

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.