-
Notifications
You must be signed in to change notification settings - Fork 14k
--show-coverage json #66472
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
--show-coverage json #66472
Conversation
cf05f04 to
1de0f21
Compare
|
Updated suggestions. |
|
☔ The latest upstream changes (presumably #54733) made this pull request unmergeable. Please resolve the merge conflicts. |
1de0f21 to
ea80202
Compare
|
cc @Centril |
|
I don't have enough experience with rustdoc to review this, sorry :) |
|
Ah my bad, since you commented I thought you felt up for this. ;) r? @kinnison |
|
What is this intended to be used for? It seems weird to reuse |
|
@ollie27 No, I prefer it this way for this simple reason that I'm working on putting back the json generation generally. That'll make more sense in a broader way. |
|
Oh also; it's a request coming from @QuietMisdreavus. :) |
|
When I ran thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error { valid_up_to: 9, error_len: Some(1) }', src/libcore/macros/mod.rs:23:13Including when trying to run the What am I doing wrong? |
|
Well if this is going to use
The motivation for a PR should be in the PR description and/or commit messages. Based on #58154 (comment) I'm going to assume that the JSON that this outputs is going to be used by some other tool in which case it doesn't need to be prettified, the filenames shouldn't be shortened and it doesn't need to include percentages or the total at the end. |
|
Ping from triage: |
|
There is nothing else for me to do except adding the full "reason". However, I'd prefer @QuietMisdreavus to provide it. |
|
☔ The latest upstream changes (presumably #67532) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I updated the description. Will fix the conflicts soon as well. |
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 think this might be what's causing #66472 (comment). Maybe you could use filename.char_indices().nth(32) instead?
ea80202 to
3c59767
Compare
|
Updated! |
src/librustdoc/config.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.
| HTML, | |
| Html, |
src/librustdoc/config.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 enum will need a third variant to represent the current output of --show-coverage. That way --show-coverage --output-format html will be an error.
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 prefer to handle it outside instead.
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.
output_format shouldn't be a field of CoverageCalculator, instead it should be passed as an argument to print_results.
src/librustdoc/html/render.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.
I think the output_format field would fit better on DocContext than RenderInfo.
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 impacting the rendering so from my point of view, it fits better here. :)
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 test should be a rustdoc-ui test so we can check the error message.
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 no reason to include the percentage in the JSON. Whatever is consuming the JSON can trivially calculate it if needed.
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 is a good point.
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.
As with the percentage, there's no reason to include the total in the JSON. It's just redundant information.
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 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.
With the percentage removed this struct isn't needed, #[derive(Serialize)] can be added to ItemCount instead.
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 would be cleaner to implement Serialize for CoverageCalculator directly.
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 the JSON is to be consumed by some other tool then it doesn't need to be pretty printed.
d54ddd3 to
d4c6522
Compare
ollie27
left a comment
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.
As this is modifying --output-format we could do with rustdoc-ui tests generating normal docs with one passing --output-format html and one passing --output-format json.
Other than those issues with the tests this looks good.
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 test doesn't yet pass on Windows because of how $DIR is normalized. Specifically
rust/src/tools/compiletest/src/runtest.rs
Lines 3213 to 3215 in abc3073
| if json { | |
| from = from.replace("\\", "\\\\"); | |
| } |
cflags.contains("--output-format json") || cflags.contains("--output-format=json") to rust/src/tools/compiletest/src/runtest.rs
Lines 3204 to 3207 in abc3073
| let json = cflags.contains("--error-format json") | |
| || cflags.contains("--error-format pretty-json") | |
| || cflags.contains("--error-format=json") | |
| || cflags.contains("--error-format=pretty-json"); |
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.
Great catch, thanks a lot!
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.
What was this supposed to test? Was there meant to be something passed to --output-format? As this test is in the coverage directory, was --show-coverage supposed to be passed here?
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 checking that it fails when no parameter is provided.
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.
In that case it shouldn't be in the coverage directory and -Z unstable-options doesn't need to be passed. However more importantly, the error this test is actually producing is error: too many file operands because compiletest is adding more arguments after --output-format which are then getting misinterpreted by rustdoc. It may be best to just drop this test.
|
☔ The latest upstream changes (presumably #69592) made this pull request unmergeable. Please resolve the merge conflicts. |
a0ea237 to
b646627
Compare
|
Removed the |
|
@ollie27 You had the majority of input on this PR -- have your raised concerns been dealt with sufficiently? |
Yeah it looks like my main concerns have been addressed so r=me. |
|
@bors r=ollie27 |
|
📌 Commit b646627 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
|
⌛ Testing commit b646627 with merge 515b9890b404a710400bff9eb167caab4b0fd1d4... |
|
@bors retry |
Rollup of 8 pull requests Successful merges: - #66472 (--show-coverage json) - #69603 (tidy: replace `make check` with `./x.py test` in documentation) - #69760 (Improve expression & attribute parsing) - #69828 (fix memory leak when vec::IntoIter panics during drop) - #69850 (panic_bounds_check: use caller_location, like PanicFnLangItem) - #69876 (Add long error explanation for E0739) - #69888 ([Miri] Use a session variable instead of checking for an env var always) - #69893 (librustc_codegen_llvm: Use slices instead of 0-terminated strings) Failed merges: r? @ghost
|
☔ The latest upstream changes (presumably #69919) made this pull request unmergeable. Please resolve the merge conflicts. |
The purpose of this change is to be able to use it as a tool in docs.rs in order to provide some more stats to crates' owners. Eventually even create a badge or something along the line.
r? @QuietMisdreavus