add target features when extracting and running doctests #49864
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
It'd be actually nice to pass compile options to tests... We should definitely talk about it! |
|
Thanks, I think that for the time being this is a good solution! It allows users to at least provide their own hidden environment (main,
If |
|
Just passing |
|
I was able to get this test to work locally, so i'm blaming the CI environment. Is there something i'm not seeing here? @gnzlbg I thought the |
QuietMisdreavus
force-pushed
the
doctest-target-features
branch
from
e7ea77d
to
3b1c3d4
Compare
| /// ``` | ||
| /// assert!(false); | ||
| /// ``` | ||
| #[cfg(target_feature = "sse")] |
There was a problem hiding this comment.
If this doctest fails, is because foo was not part of the binary, so... "sse" is not set for some reason, which is very weird. It is set for x86_64 always. cc @alexcrichton
There was a problem hiding this comment.
Hm I'm not sure why this isn't working, rustc +nightly --print cfg clearly shows it's there.
There was a problem hiding this comment.
If you run the test locally (i.e. x.py test --stage 1 src/test/rustdoc --test-args "target-feature") then it will work properly, implying there's something off with the Travis setup.
There was a problem hiding this comment.
Aha right yes, you can tag this as // no-system-llvm
QuietMisdreavus
force-pushed
the
doctest-target-features
branch
from
3b1c3d4
to
9e0e263
Compare
QuietMisdreavus
force-pushed
the
doctest-target-features
branch
from
9e0e263
to
3366032
Compare
Well, this makes travis skip the test at least. It still runs and passes locally on my system, too, so hopefully it works this time. I've reverted the test to the original version (that has feature detection both on the item and in the test) and squashed it down. If travis still agrees (i.e. skips the test) then this PR is ready. I have a local branch waiting for this to add a |
|
Alright, passed travis! @GuillaumeGomez ready for review! |
|
@alexcrichton what was the problem? IIRC there is some stuff with target features that we are only doing with Rust's LLVM, was that it? |
|
We can only read a list of target features from our own LLVM, not system LLVMs |
|
Let's go then! @bors: r+ |
|
📌 Commit 3366032 has been approved by |
bors
added
S-waiting-on-bors
…ures, r=GuillaumeGomez add target features when extracting and running doctests When rendering documentation, rustdoc will happily load target features into the cfg environment from the current target, but fails to do this when doing anything with doctests. This would lead to situations where, thanks to rust-lang#48759, functions tagged with `#[target_feature]` couldn't run doctests, thanks to the automatic `#[doc(cfg(target_feature = "..."))]`. Currently, there's no way to pass codegen options to rustdoc that will affect its rustc sessions, but for now this will let you use target features that come default on the platform you're targeting. Fixes rust-lang#49723
rustdoc: port the -C option from rustc Blocked on #49864. The included test won't work without those changes, so this PR includes those commits as well. When documenting items that require certain target features, it helps to be able to force those target features into existence. Rather than include a flag just to parse those features, i instead decided to port the `-C` flag from rustc in its entirety. It takes the same parameters, because it runs through the same parsing function. This has the added benefit of being able to control the codegen of doctests as well. One concern i have with the flag is that i set it to stable here. My rationale is that it is a direct port of functionality on rustc that is currently stable, used only in mechanisms that it is originally used for. If needed, i can set it back to be unstable.
When rendering documentation, rustdoc will happily load target features into the cfg environment from the current target, but fails to do this when doing anything with doctests. This would lead to situations where, thanks to #48759, functions tagged with
#[target_feature]couldn't run doctests, thanks to the automatic#[doc(cfg(target_feature = "..."))].Currently, there's no way to pass codegen options to rustdoc that will affect its rustc sessions, but for now this will let you use target features that come default on the platform you're targeting.
Fixes #49723