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

added --no-run option for rustdoc #83857

Merged
merged 11 commits into from
May 1, 2021
Merged

added --no-run option for rustdoc #83857

merged 11 commits into from
May 1, 2021

Conversation

ABouttefeux
Copy link
Contributor

@ABouttefeux ABouttefeux commented Apr 4, 2021

resolve #59053

add --no-run option for rustdoc for compiling doc test but not running them.
Intended for use with --persist-doctests.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @CraftSpider (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 4, 2021
@ABouttefeux ABouttefeux changed the title added --no-run option added --no-run option for rustdoc Apr 4, 2021
@rust-log-analyzer

This comment has been minimized.

@@ -121,6 +121,8 @@ crate struct Options {
/// For example, using ignore-foo to ignore running the doctest on any target that
/// contains "foo" as a substring
crate enable_per_target_ignores: bool,
/// Compile test but do not run them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could tell others that this is the opposite of should_test?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the opposite, they do different things (and no_run requires should_test to also be set).

Copy link
Contributor

@pickfire pickfire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me (but not sure if it's working).

@rust-log-analyzer

This comment has been minimized.

Comment on lines +3 to +9
test $DIR/no-run-flag.rs - f (line 11) ... ok
test $DIR/no-run-flag.rs - f (line 14) ... ignored
test $DIR/no-run-flag.rs - f (line 17) ... ok
test $DIR/no-run-flag.rs - f (line 23) ... ok
test $DIR/no-run-flag.rs - f (line 28) ... ok
test $DIR/no-run-flag.rs - f (line 32) ... ok
test $DIR/no-run-flag.rs - f (line 8) ... ok
Copy link
Contributor

@pickfire pickfire Apr 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it didn't run why is it "ok"? IIRC that is the same as test passing right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so adding the --no-run flag change the behavior of the test like it was annotated as ```no_run. Maybe this is unwanted and something else should be displayed.

Copy link
Contributor

@pickfire pickfire Apr 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @CraftSpider @jyn514 should we have a different text? "ok" may be confusing since it didn't run. Also note that we may also want a different color or the same color as "ignored".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I don't think 'ignored' is quite right, but 'ok' is also a bit confusing. If we can make it something new, maybe something like 'built' or 'checked'? If not, I think 'ok' is more accurate than 'ignored'.
Color-wise, I'm fine with it being ok colored, as it is a requested change to behavior, not implicit, so it's requested to treat it as success. If that makes sense.

Copy link
Contributor Author

@ABouttefeux ABouttefeux Apr 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After investigations I think that in order to do so, I have to modify the lib test. This will also affect all tests and not just doctests. Do you think this is a worthwhile investment and should this be in a different PR ? Anyway I would be interested in implementing that but the scope is a bit bigger than I anticipated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no_run by itself is useless.
To summarize:

  • if you run rustdoc -Z unstable-options --no-run it just build the documentation, it has the same behavior as just rustdoc
  • rustdoc -Z unstable-options --no-run --test run the doctest set. It behave as if every test had the no_run meaning they won't run. Meaning that test like
    ```
    panic!()
    ```
    will print as ok like
    ```no_run
    panic!()
    ```
    without the --no-run flag

I agree that is confusing. Maybe a error should be raised if no_run is active and not should_test. However I think that if you run rustdoc -Z unstable-options --no-run your intention was probably to run the test instead of documenting your project.

I assume that in the original issue the final goal would be to be able to generate bin (with --persist-doctests) but without running them.

Or maybe a another possible case would be to unify the behavior of cargo test --no-run (provided that down the line cargo is also modified). For instance cargo test --all test both regular test and doctest but cargo test --all --no-run skips doctest cargo test --doc --no-run give an error.

Now if the explicit goal is to harmonize with regular test the output should just be empty.
Another option would for me to change the test lib such that no_run test display something like test foo ... checked, provided that such change is desirable (to discuss thought the RFC process ?).
Moreover test with compile_fail should also print something different maybe checked is also desirable.

I am new contributing for rust so I am not quite sure of what to do to solve this issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that is confusing. Maybe a error should be raised if no_run is active and not should_test. However I think that if you run rustdoc -Z unstable-options --no-run your intention was probably to run the test instead of documenting your project.

I think we should give a hard error here; if people meant to run the test they can add --test. Could you suggest adding --test in the error message?

See

} else if !out_fmt.is_json() && show_coverage {
diag.struct_err(
"html output format isn't supported for the --show-coverage option",
)
.emit();
return Err(1);
}
for an example of how to give an error if the options are inconsistent.

I think all your other changes can go in a follow-up PR, I don't think we should be changing libtest here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok thank you. I have not change libtest yet I will work on that too :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not change libtest in this pr. I am not a maintainer and don't know who to ask to approve; finding out will delay landing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I was not clear. I will do another PR for libtest

@JohnCSimon
Copy link
Member

Ping from triage:
@ABouttefeux assigning back to author, thanks.
@rustbot label: -S-waiting-on-review +S-waiting-on-author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 26, 2021
@ABouttefeux
Copy link
Contributor Author

At this moment it is unclear for me what is wanted. Could someone clarify this please ?

@jyn514 jyn514 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 26, 2021
@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 26, 2021
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, just a couple nits :) r=me with those addressed.

@jyn514
Copy link
Member

jyn514 commented May 1, 2021

@bors r+

@bors
Copy link
Contributor

bors commented May 1, 2021

📌 Commit 03c710b has been approved by jyn514

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 1, 2021
@bors
Copy link
Contributor

bors commented May 1, 2021

⌛ Testing commit 03c710b with merge 5f304a5...

@bors
Copy link
Contributor

bors commented May 1, 2021

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing 5f304a5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 1, 2021
@bors bors merged commit 5f304a5 into rust-lang:master May 1, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 1, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 5, 2021
Show test type during prints

Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.

During rust-lang#83857 I got the feedback that test output can be confusing.

For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```

I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".

------------

Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jun 5, 2021
Show test type during prints

Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.

During rust-lang#83857 I got the feedback that test output can be confusing.

For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```

I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".

------------

Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 6, 2021
Show test type during prints

Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.

During rust-lang#83857 I got the feedback that test output can be confusing.

For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```

I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".

------------

Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use --no-run with doctests now there is --persist-doctests
9 participants