-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Propagate custom cfg directives to rustdoc and doctests #2050
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
Conversation
|
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
src/cargo/ops/cargo_rustc/mod.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll want to do a hash lookup here to ensure that you're doing the right thing in a cross-compilation scenario. Right now this ignores the Kind which is an important distinction for target/host compiles.
The Kind to use in the key should be present in unit.kind right before the work is created, and that should do the trick!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I wasn't sure whether the kind mattered here.
|
Awesome, thanks @gkoz! |
|
Updated for both comments. |
|
@alexcrichton looks like you don't have `Rolling builds" enabled in appveyor project settings. Because of this it doesn't stop building stale commits promptly and takes longer to get to the current ones. |
src/cargo/ops/cargo_rustc/mod.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This'll actually want to drop the lock ASAP instead of holding it over the entire call to rustdoc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, right 😳
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you put it like this then? It's a lot on one line and not very obvious that the lock will get released.
if let Some(output) = build_state.outputs.lock().unwrap().get(&key) {
for cfg in output.cfgs.iter() {
rustdoc.arg("--cfg").arg(cfg);
}
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the alternative is putting everything into an explicit block, not very nice looking either. Or explicit drop perhaps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or
if let Ok(outputs) = build_state.outputs.lock() {
if let Some(output) = outputs.get(&key) {
for cfg in output.cfgs.iter() {
rustdoc.arg("--cfg").arg(cfg);
}
}
}
/*
else {
return_an_error?
}
*/|
Whoa, I had no idea that option existed! I've turned it on now |
|
I went with the more concise version giving the lock up after iterating over cfgs. At least I believe its lifetime will now be limited to the |
|
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
Fixes #1980