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

Set environment variable for doctests #9886

Closed
CobaltCause opened this issue Sep 8, 2021 · 2 comments
Closed

Set environment variable for doctests #9886

CobaltCause opened this issue Sep 8, 2021 · 2 comments
Labels
A-doctests Area: rustdoc --test C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@CobaltCause
Copy link

Describe the problem you are trying to solve

Currently, it's possible to detect whether a procedural macro is being used in a normal context (i.e. library or binary crate) or integration test depending on whether the CARGO_TARGET_TMPDIR environment variable is set. This is very useful for proc-macro-crate, which allows usage of a proc macro using types from a crate in the crate defining those types. However, there appears to be no way to distinguish between being used in a "normal context" and being used in doctests.

Describe the solution you'd like

In order to allow this, I think either CARGO_TARGET_TMPDIR should be set for doctests if that makes any sense, or a new environment variable should be introduced that indicates that the current build is for a doctest.

Notes

See also this issue: bkchr/proc-macro-crate#10

@CobaltCause CobaltCause added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Sep 8, 2021
@ehuss ehuss added the A-doctests Area: rustdoc --test label Sep 11, 2021
@weihanglo weihanglo added the S-triage Status: This issue is waiting on initial triage. label May 14, 2023
@weihanglo
Copy link
Member

I feel like CARGO_TARGET_TMPDIR just happened to be there. It wasn't designed for detecting compile mode. Setting CARGO_TARGET_TMPDIR for doctests seems like an anti-pattern to me, as doctests should be independent like unit tests as possible as they could. To be fair, I don't feel like crate compilation should be aware of any compiling context, except build scripts.

However, proc-macros are a bit special. People use it like a build script, so… not sure at all.

At this time, I would suggest using workspace and have a test suite member, like how serde is doing: https://github.com/serde-rs/serde/tree/7b548db91ed7da81a5c0ddbd6f6f21238aacfebe/test_suite

@weihanglo weihanglo added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-triage Status: This issue is waiting on initial triage. labels Aug 17, 2023
@CobaltCause
Copy link
Author

Oh sorry, I actually meant to close this once I found rust-lang/rust#54363 but forgot about it. It seems to me like the solution proposed in rust-lang/rust#54363 (comment) might fix this problem? In any case I think that issue is better in that it's about solving the underlying problem instead of applying random bandaids like suggested here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-doctests Area: rustdoc --test C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

3 participants