also export metrics from librustdoc #140815
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @notriddle rustbot has assigned @notriddle. Use |
rustbot
added
S-waiting-on-review
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
GuillaumeGomez
approved these changes
May 9, 2025
|
Thanks! @bors r+ rollup |
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 9, 2025
…Gomez also export metrics from librustdoc Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331) The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published. This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled. Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 9, 2025
…Gomez also export metrics from librustdoc Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331) The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published. This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled. Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 9, 2025
…Gomez also export metrics from librustdoc Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331) The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published. This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled. Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#139863 (rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg`) - rust-lang#140815 (also export metrics from librustdoc) - rust-lang#140819 (Add regression test for 125877) - rust-lang#140843 (Fix `broken-pipe-no-ice` run-make test for rpath-less builds) - rust-lang#140848 (Improved error message for top-level or-patterns) - rust-lang#140852 (Update the edition guide for let chains) - rust-lang#140864 (Last minute relnotes fix) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 10, 2025
Rollup merge of rust-lang#140815 - yaahc:rustdoc-metrics, r=GuillaumeGomez also export metrics from librustdoc Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331) The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published. This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled. Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses the issue mentioned here: #t-docs-rs > metrics intitiative @ 💬
The previous implementation only emitted metrics from rustc, but it turns out running
cargo doconly callsrustcfor dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci viacargo docso as things stood this would not emit any metrics for any of the crates themselves that were published.This change adds the same logic from
rustc_driver_impltolibrustdocto also dump metrics at the end of its execution if they are enabled.Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.