-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add --doctest-compilation-args
option to add compilation flags to doctest compilation
#128780
Conversation
This comment has been minimized.
This comment has been minimized.
7d5d19d
to
50f8136
Compare
Forgot to normalize doctests output in the test... |
This comment has been minimized.
This comment has been minimized.
50f8136
to
d906824
Compare
And this time I normalized the time... Hopefully I didn't forget anything again. |
d906824
to
4a7337c
Compare
src/librustdoc/doctest.rs
Outdated
// the doctest. | ||
if let Ok(rustflags) = std::env::var("RUSTFLAGS") { | ||
// Very simple parsing implementation. Might be a good idea to correctly handle strings. | ||
for flag in rustflags.split(' ').map(|flag| flag.trim()).filter(|flag| !flag.is_empty()) { |
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.
for flag in rustflags.split(' ').map(|flag| flag.trim()).filter(|flag| !flag.is_empty()) { | |
for flag in rustflags.split_whitespace().map(|flag| flag.trim()).filter(|flag| !flag.is_empty()) { |
I went hunting through cargo's source code for info on this, and I hope someone can correct me on this, but it looks like this is the function that does the splitting:
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.
I saw it but I'm not a big fan of this approach. Parsing a shell command is not too complicated. Just not sure it's worth it here.
I'll update with your suggestion though.
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.
Yeah, I understand. I brought it up because I figured, if both tools are going to consult the same env variable, then they should both parse it the same way.
The TOML wrapping is behind an unstable flag anyway.
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.
Might be worth doing a small rewrite of their code. Putting that in my todo list.
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.
(compiletest
has the same problems of splitting rustflags and env vars and such naively on whitespace)
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 definitely must parse the variable the same way cargo does, everything else is going to cause nasty surprises.
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.
Here is what Miri does, which we took from cargo originally:
That does seem to be equal to what this PR does.
4a7337c
to
9d90942
Compare
@rfcbot fcp merge The env vars are an API, so covered by stability promise. |
Team member @notriddle has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
This won't take into account the dozen other ways to specify rustc flags to |
I wasn't sure adding a new command line flag was a good idea, but thinking about it some more, I think you're right. What do you think about |
9d90942
to
b8ee921
Compare
RUSTFLAGS
environment variable when compiling doctests--doctest-compilation-args
option to add compilation flags to doctest compilation
I replaced the usage of |
b8ee921
to
babc9ef
Compare
src/librustdoc/doctest.rs
Outdated
.filter(|flag| !flag.is_empty()) | ||
{ | ||
// Very simple parsing implementation. Might be a good idea to correctly handle strings. | ||
content.push(flag.to_string()); |
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 has been brought up a load of times, but I'm not sure this is the right thing to do here? Is there any prior art for passing flags down from a flag (and not an env-var).
(The good news is that this isn't insta-stable, so we can change the edge-behaviour later before stabilization)
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.
There's two correct options I know of:
- Pass one flag at a time
--doctest-compilation-arg -Dwarnings --doctest-compilation-arg -Adead-code
- Pass the flags as a single string in a proper encoding, such as toml
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.
Pass one flag at a time
--doctest-compilation-arg -Dwarnings --doctest-compilation-arg -Adead-code
.
You can currently do it with the option. :)
Pass the flags as a single string in a proper encoding, such as toml
That could work too, but I'm not sure if it's something common enough to justify it here. Parsing shell quotes would be much simpler.
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 has been brought up a load of times, but I'm not sure this is the right thing to do here? Is there any prior art for passing flags down from a flag (and not an env-var).
(The good news is that this isn't insta-stable, so we can change the edge-behaviour later before stabilization)
We have --test-args
in rustdoc which allows it.
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 can currently do it with the option. :)
No, the current implementation would mishandle trying to pass a space containing arg.
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.
Yes, I meant passing the same option flag multiple times.
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.
Code has evolved quite a lot since then. It's now how you would expect a shell environment to parse the command.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
a5162c6
to
16b85df
Compare
|
||
The parsing of arguments works as follows: if it encounters a `"` or a `'`, it will continue | ||
until it finds the character unescaped (without a prepending `\`). If not inside a string, a | ||
whitespace character will also split arguments. Example: |
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.
That does not match shell -- in shell, you cannot do any escaping inside '
.
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.
Interesting! Gonna change this behaviour then.
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.
I'm not a fan of us having a re-implementation of shell word splitting in the repo. We'll inevitably get it wrong in subtle ways. I think we should, if at all possible, avoid having to do word splitting.
If some word splitting is needed, then given that RUSTFLAGS can get by without any quote handling, it might be better to just remain consistent with that. Or alternatively, if the flag is only meant to be set by machines, we could use the format used by CARGO_ENCODED_RUSTFLAGS.
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.
Actually I'm gonna keep the current behaviour. It's not exactly like a shell would do, but it's fully described in the book and in any case it's unstable until further notice, so if users are unhappy with this format, nothing prevents us from changing it in the future.
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.
If you land this on nightly with completely non-standard behavior (as seems to be the case right now), there's a chance that it's going to be hard to change later. We don't have to make the final call now, but the implementation should at least do something that plausibly could be the final version, and I would say right now that is not the case.
Also, please make sure this is explicitly listed in the tracking issue so that this is discussed before stabilization. Where is that tracking issue, anyway?
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.
It's #134172. Adding it into the first comment as well.
This comment has been minimized.
This comment has been minimized.
82417a4
to
a4411e0
Compare
This comment has been minimized.
This comment has been minimized.
a4411e0
to
de4890b
Compare
This comment has been minimized.
This comment has been minimized.
de4890b
to
2d914be
Compare
Seems like I updated all tests and added missing docs so ready to go. @bors r=rustdoc |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#123604 (Abstract `ProcThreadAttributeList` into its own struct) - rust-lang#128780 (Add `--doctest-compilation-args` option to add compilation flags to doctest compilation) - rust-lang#133782 (Precedence improvements: closures and jumps) - rust-lang#134509 (Arbitrary self types v2: niche deshadowing test) - rust-lang#134524 (Arbitrary self types v2: no deshadow pre feature.) - rust-lang#134539 (Restrict `#[non_exaustive]` on structs with default field values) - rust-lang#134586 (Also lint on option of function pointer comparisons) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128780 - GuillaumeGomez:rustflags-doctests, r=rustdoc Add `--doctest-compilation-args` option to add compilation flags to doctest compilation Fixes rust-lang#67533. Tracking issue: rust-lang#134172 It's been something I meant to take a look at for a long time and actually completely forgot... The idea is to allow to give more control over how doctests are compiled to users. To do so, this PR adds a new `--doctest-compilation-args` option which provides extra compilation flags. r? `@notriddle`
Fixes #67533.
Tracking issue: #134172
It's been something I meant to take a look at for a long time and actually completely forgot... The idea is to allow to give more control over how doctests are compiled to users. To do so, this PR adds a new
--doctest-compilation-args
option which provides extra compilation flags.r? @notriddle