Skip to content

neither RUSTFLAGS nor RUSTDOCFLAGS passed to rustdoc by "cargo test --doc" #123424

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

Closed
decathorpe opened this issue Apr 3, 2024 · 4 comments
Closed
Labels
C-bug Category: This is a bug.

Comments

@decathorpe
Copy link

We're running cargo test for many Rust crates we package in Fedora Linux to ensure they work in our environment and on all CPU architectures that we support. We define RUSTFLAGS="--cap-lints=warn" (among other things) to avoid crates starting to fail to build due to things like #![deny(warnings)] with newer Rust versions that add new lints.

Passing "--cap-lints=warn" with RUSTFLAGS works fine for normal library code and test code, but it doesn't get applied to rustdoc when it checks / compiles doctests, and this often causes problems because many crates use #![deny(warnings)] for their doctests / example code in doc comments.

I tried defining RUSTDOCFLAGS="--cap-lints=warn" in addition to having this flag already present in RUSTFLAGS, it didn't change the behaviour. I tried adding a build.rustdocflags = "--cap-lints=warn" setting to .cargo/config, and it didn't change anything either.

It appears that cargo test --doc isn't passing either RUSTFLAGS or RUSTDOCFLAGS to rustdoc correctly.

@decathorpe decathorpe added the C-bug Category: This is a bug. label Apr 3, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 3, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Apr 3, 2024

Should this issue be instead filed over at cargo? This doesn't seem to involve rustc and seems to be cargo specific.

@decathorpe
Copy link
Author

Ah, I missed that cargo is developed in a separate repository. Should I move this issue there?

@jieyouxu
Copy link
Member

jieyouxu commented Apr 3, 2024

Yeah, would make more sense. Thanks!

@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 3, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Apr 3, 2024

Going to close this issue as it's more suitable for the cargo repo.

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.
Projects
None yet
Development

No branches or pull requests

3 participants