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

--show-coverage json #66472

Merged
merged 6 commits into from
Mar 11, 2020
Merged

--show-coverage json #66472

merged 6 commits into from
Mar 11, 2020

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Nov 16, 2019

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

@JohnTitor JohnTitor added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 16, 2019
@GuillaumeGomez
Copy link
Member Author

Updated suggestions.

@bors
Copy link
Contributor

bors commented Nov 18, 2019

☔ The latest upstream changes (presumably #54733) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez
Copy link
Member Author

cc @Centril

@Centril
Copy link
Contributor

Centril commented Nov 21, 2019

I don't have enough experience with rustdoc to review this, sorry :)

@GuillaumeGomez
Copy link
Member Author

Ah my bad, since you commented I thought you felt up for this. ;)

r? @kinnison

@ollie27
Copy link
Member

ollie27 commented Nov 21, 2019

What is this intended to be used for?

It seems weird to reuse --output-format for this because the current output of --show-coverage is definitely not HTML. How about modifying --show-coverage to take and argument so we'd have something like --show-coverage table and --show-coverage json?

@GuillaumeGomez
Copy link
Member Author

@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.

@GuillaumeGomez
Copy link
Member Author

Oh also; it's a request coming from @QuietMisdreavus. :)

@kinnison
Copy link
Contributor

When I ran ./x.py test --stage 1 --keep-stage 1 src/test/rustdoc-ui I got a significant number of:

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:13

Including when trying to run the coverage/json.rs which this PR includes.

What am I doing wrong?

@ollie27
Copy link
Member

ollie27 commented Nov 22, 2019

Well if this is going to use --output-format then it needs another variant like --output-format table for the current output of --show-coverage. --show-coverage --output-format html should be an error because the output is not HTML.

Oh also; it's a request coming from @QuietMisdreavus. :)

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.

@JohnCSimon JohnCSimon 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 Nov 30, 2019
@JohnCSimon
Copy link
Member

Ping from triage:
@GuillaumeGomez can you address the comments above?
thanks.

@GuillaumeGomez
Copy link
Member Author

There is nothing else for me to do except adding the full "reason". However, I'd prefer @QuietMisdreavus to provide it.

@Dylan-DPC-zz Dylan-DPC-zz added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 1, 2019
@bors
Copy link
Contributor

bors commented Dec 22, 2019

☔ The latest upstream changes (presumably #67532) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez
Copy link
Member Author

I updated the description. Will fix the conflicts soon as well.

// FIXME(misdreavus): this needs to count graphemes, and probably also track
// double-wide characters...
if filename.len() > 35 {
"...".to_string() + &filename[filename.len() - 32..]
Copy link
Member

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?

@GuillaumeGomez
Copy link
Member Author

Updated!

#[derive(Clone, Copy, PartialEq, Eq, Debug)]
pub enum OutputFormat {
Json,
HTML,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
HTML,
Html,

#[derive(Clone, Copy, PartialEq, Eq, Debug)]
pub enum OutputFormat {
Json,
HTML,
Copy link
Member

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.

Copy link
Member Author

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.

struct CoverageCalculator {
items: BTreeMap<FileName, ItemCount>,
output_format: Option<OutputFormat>,
Copy link
Member

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.

@@ -270,6 +270,7 @@ pub struct RenderInfo {
pub deref_trait_did: Option<DefId>,
pub deref_mut_trait_did: Option<DefId>,
pub owned_box_did: Option<DefId>,
pub output_format: Option<OutputFormat>,
Copy link
Member

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.

Copy link
Member Author

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. :)

@@ -0,0 +1,5 @@
// compile-flags:-Z unstable-options --output-format
Copy link
Member

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.

struct CoverageCalculatorEntry {
documented: u64,
total: u64,
percentage: f64,
Copy link
Member

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.

Copy link
Member Author

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.

})
.collect::<BTreeMap<String, CoverageCalculatorEntry>>();
json.insert(
"total".to_owned(),
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

👍

}

#[derive(Serialize)]
struct CoverageCalculatorEntry {
Copy link
Member

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.

CoverageCalculator { items: Default::default(), output_format }
}

fn to_json(&self) -> String {
Copy link
Member

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.

percentage: total.percentage().unwrap_or(0.0),
},
);
serde_json::to_string_pretty(&json).expect("failed to convert JSON data to string")
Copy link
Member

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.

@GuillaumeGomez
Copy link
Member Author

@kinnison I rewrote the commit history to make it simpler to follow. Normally I already fixed all @ollie27's comments (unless I forgot one?).

Copy link
Member

@ollie27 ollie27 left a 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.

@@ -0,0 +1 @@
{"$DIR/json.rs":{"total":13,"with_docs":7}}
Copy link
Member

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

if json {
from = from.replace("\\", "\\\\");
}
isn't being triggered but is needed in this case. This can be fixed by adding cflags.contains("--output-format json") || cflags.contains("--output-format=json") to
let json = cflags.contains("--error-format json")
|| cflags.contains("--error-format pretty-json")
|| cflags.contains("--error-format=json")
|| cflags.contains("--error-format=pretty-json");
.

Copy link
Member Author

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!

@@ -0,0 +1,4 @@
// compile-flags:-Z unstable-options --output-format
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

@bors
Copy link
Contributor

bors commented Mar 1, 2020

☔ The latest upstream changes (presumably #69592) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez
Copy link
Member Author

Removed the output-format test as well.

@kinnison
Copy link
Contributor

kinnison commented Mar 8, 2020

@ollie27 You had the majority of input on this PR -- have your raised concerns been dealt with sufficiently?

@ollie27
Copy link
Member

ollie27 commented Mar 10, 2020

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.

@kinnison
Copy link
Contributor

@bors r=ollie27

@bors
Copy link
Contributor

bors commented Mar 10, 2020

📌 Commit b646627 has been approved by ollie27

@bors
Copy link
Contributor

bors commented Mar 10, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@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. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Mar 10, 2020
@bors
Copy link
Contributor

bors commented Mar 11, 2020

⌛ Testing commit b646627 with merge 515b9890b404a710400bff9eb167caab4b0fd1d4...

@Centril
Copy link
Contributor

Centril commented Mar 11, 2020

@bors retry

bors added a commit that referenced this pull request Mar 11, 2020
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
@bors
Copy link
Contributor

bors commented Mar 11, 2020

⌛ Testing commit b646627 with merge c20d7ee...

@bors
Copy link
Contributor

bors commented Mar 11, 2020

☔ The latest upstream changes (presumably #69919) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 11, 2020
@bors bors merged commit 741d4ff into rust-lang:master Mar 11, 2020
@GuillaumeGomez GuillaumeGomez deleted the show-coverage-json branch March 12, 2020 10:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants