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

Add a mode for reading docs.rs metadata when running rustdoc #543

Merged
merged 1 commit into from
Apr 25, 2022

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Sep 5, 2020

Closes #532

Before merging, I need to publish the docsrs-metadata package to crates.io so crater doesn't depend on a git version.

@pietroalbini
Copy link
Member

What's the backtrace of that error?

@jyn514
Copy link
Member Author

jyn514 commented Sep 7, 2020

Backtrace
[2020-09-07T12:02:36Z INFO  rustwide::workspace] updating the local crates.io registry clone
[2020-09-07T12:02:36Z INFO  rustwide::cmd] running `Command { std: "/home/joshua/src/rust/crater/work/cargo-home/bin/cargo" "+stable" "install" "lazy_static", kill_on_drop: false }`
[2020-09-07T12:02:36Z INFO  rustwide::cmd] [stderr]     Updating crates.io index
[2020-09-07T12:02:36Z INFO  rustwide::cmd] [stderr] error: specified package `lazy_static v1.4.0` has no binaries
[2020-09-07T12:02:36Z ERROR crater::utils] Permission denied (os error 13)
[2020-09-07T12:02:37Z ERROR crater::utils] stack backtrace:
   0:     0x562ac63b9333 - backtrace::backtrace::libunwind::trace::hbd861e8e3f31d51d
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/backtrace/libunwind.rs:53
                         - backtrace::backtrace::trace::h515fd9931dbc6069
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/backtrace/mod.rs:42
   1:     0x562ac63b37e3 - backtrace::capture::Backtrace::new_unresolved::hcfdb6317fef53443
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/capture.rs:88
   2:     0x562ac63b1345 - failure::backtrace::internal::InternalBacktrace::new::h217cbb5de2b4997f
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.3/src/backtrace/internal.rs:44
   3:     0x562ac63b10ac - failure::backtrace::Backtrace::new::h26b67c9715a7ab27
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.3/src/backtrace/mod.rs:111
   4:     0x562ac5eb1daf - <failure::error::error_impl::ErrorImpl as core::convert::From<F>>::from::h79c88be113e866e8
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.3/src/error/error_impl.rs:19
   5:     0x562ac5e6aaef - <failure::error::Error as core::convert::From<F>>::from::hf3e5c4aee62bf5b3
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.3/src/error/mod.rs:36
   6:     0x562ac5e9a2bc - rustwide::workspace::Workspace::purge_all_build_dirs::h478bcbfb00baa2b5
                        at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.10.0/src/workspace.rs:216
   7:     0x562ac47dfb03 - crater::cli::Crater::run::h3f0e657e8a314220
                        at src/cli.rs:489
   8:     0x562ac4805dab - crater::main_::h784f3df6d7d2e685
                        at src/main.rs:56
   9:     0x562ac47bb768 - core::ops::function::FnOnce::call_once::h1febd8c8a5321857
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ops/function.rs:233
  10:     0x562ac47d1097 - std::panicking::try::do_call::h35ae630dd1a66384
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:348
  11:     0x562ac47d13fc - __rust_try
  12:     0x562ac47d0ee3 - std::panicking::try::h961360845d069046
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:325
  13:     0x562ac48002d0 - std::panic::catch_unwind::h942bd588c06aa04c
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panic.rs:394
  14:     0x562ac4805911 - crater::main::h86893e5ca9ae0eeb
                        at src/main.rs:33
  15:     0x562ac47ffcea - std::rt::lang_start::{{closure}}::h544fec4b409681ee
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  16:     0x562ac693f582 - std::rt::lang_start_internal::{{closure}}::h5d3ea623498f5f43
                        at src/libstd/rt.rs:52
                         - std::panicking::try::do_call::hac65e71be769a440
                        at src/libstd/panicking.rs:348
                         - std::panicking::try::hd4706e264bcf6712
                        at src/libstd/panicking.rs:325
                         - std::panic::catch_unwind::h948a0fb4a8b3ee82
                        at src/libstd/panic.rs:394
                         - std::rt::lang_start_internal::h72cc068ed2d0ac53
                        at src/libstd/rt.rs:51
  17:     0x562ac47ffcc6 - std::rt::lang_start::h314ac92e168f8730
                        at /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  18:     0x562ac4805e29 - main
  19:     0x7fe76efb50b2 - __libc_start_main
  20:     0x562ac47b302d - _start
  21:                0x0 - <unknown>
[2020-09-07T12:02:37Z INFO  crater] command failed

@jyn514
Copy link
Member Author

jyn514 commented Sep 7, 2020

Huh, so it looks like it's not actually related to lazy_static? Don't have time to debug right now but I'll try to pick it up again this weekend.

@pietroalbini
Copy link
Member

Hmm, try manually removing work?

@jyn514
Copy link
Member Author

jyn514 commented Sep 7, 2020

This looks like it was the issue:

rm: cannot remove 'work/builds/worker-0/source': Permission denied
rm: cannot remove 'work/builds/worker-0/target': Permission denied

I removed them both with sudo and now things seem to be working.
Is it possible to give a better error message when this fails? Even printing the name of the directory would have been enough to figure it out.

@pietroalbini
Copy link
Member

Sure, but this needs to be handled on the rustwide side.

@jyn514
Copy link
Member Author

jyn514 commented Sep 10, 2020

It looks like this is also a crater bug: whenever you interrupt the process (with Ctrl+C) it will leave around files owned by root, causing it to fail the next time you run tests.

@jyn514
Copy link
Member Author

jyn514 commented Sep 10, 2020

I don't think there are any existing tests for rustdoc, is that right? I ran a build that always fails with cfg(doc) but it still succeeded.

@jyn514
Copy link
Member Author

jyn514 commented Sep 10, 2020

Is there a way to run a minicrater test against only some crates, instead of all of them? Right now doc_small takes a very long time to run, but I only need to test it against one crater. I have

    doc_small {
        ex: "doc",
        crate_select: "local",
        mode: "rustdoc",
        ..Default::default()
    },

and

local-crates = ["build-pass", "docs-rs-features"]

which makes it seem like only 2 crates should be run, but it's running all of them.

@jyn514
Copy link
Member Author

jyn514 commented Sep 10, 2020

I tried this diff:

diff --git a/src/config.rs b/src/config.rs
index a7e1c08..bdbe514 100644
--- a/src/config.rs
+++ b/src/config.rs
@@ -119,7 +119,9 @@ impl Config {
     }
 
     pub fn should_skip(&self, c: &Crate) -> bool {
-        self.crate_config(c).map(|c| c.skip).unwrap_or(false)
+        // Default to `true` for local crates so it doesn't always run every test
+        let default_skip = matches!(c, Crate::Local(_));
+        self.crate_config(c).map(|c| c.skip).unwrap_or(default_skip)
     }
 
     pub fn should_skip_tests(&self, c: &Crate) -> bool {

but it ended up skipping every crate, even crates with { skip = false }. So giving up on that for now, better too many tests than too few.

@pietroalbini
Copy link
Member

@jyn514 crate_select needs to be demo in your minicrater build configuration.

Comment on lines 26 to 34
"res": "spurious-fixed",
"res": "test-pass",
"runs": [
{
"log": "stable/local/memory-hungry",
"res": "build-fail:oom"
"res": "test-pass"
},
{
"log": "beta/local/memory-hungry",
"res": "test-fail:oom"
"res": "test-pass"
Copy link
Member

Choose a reason for hiding this comment

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

This should not have been blessed.

Copy link
Member Author

Choose a reason for hiding this comment

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

How can I make sure my changes are right if they're different on CI and locally?

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 ended up only running minicrater::doc which seems to work well enough. But I'd have the same question if I needed to modify resource_exhaustion.

@jyn514

This comment has been minimized.

@pietroalbini
Copy link
Member

@bors try

@pietroalbini
Copy link
Member

@bors try again

bors added a commit that referenced this pull request Oct 16, 2020
[WIP] Read docs.rs metadata when running rustdoc

Closes #532

<details><summary>Outdated errors</summary>

I'm having trouble running the test suite, so I haven't yet added a test. My idea was to have a crate that only builds successfully when you read the metadata, but I'm not sure if that would work with the way the test suite is set up.

Current errors:
```
$ cargo test minicrater -- single_thread_small --ignored --test-threads 1
[2020-09-05T02:02:04Z INFO  rustwide::cmd] running `Command { std: "/home/joshua/src/rust/crater/work/cargo-home/bin/cargo" "+stable" "install" "lazy_static", kill_on_drop: false }`
[2020-09-05T02:02:04Z INFO  rustwide::cmd] [stderr]     Updating crates.io index
[2020-09-05T02:02:04Z INFO  rustwide::cmd] [stderr] error: specified package `lazy_static v1.4.0` has no binaries
[2020-09-05T02:02:04Z ERROR crater::utils] Permission denied (os error 13)
[2020-09-05T02:02:04Z ERROR crater::utils] note: run with `RUST_BACKTRACE=1` to display a backtrace.
[2020-09-05T02:02:04Z INFO  crater] command failed
', /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-0.10.1/src/assert.rs:154:13
```

</details>

Before merging, I need to publish the `docsrs-metadata` package to crates.io so crater doesn't depend on a git version.

r? `@pietroalbini` help
@bors
Copy link
Collaborator

bors commented Oct 16, 2020

⌛ Trying commit 4d1fd47 with merge 45d86f6...

@bors
Copy link
Collaborator

bors commented Oct 16, 2020

💔 Test failed - checks-actions

@pietroalbini
Copy link
Member

@bors try

bors added a commit that referenced this pull request Oct 19, 2020
[WIP] Read docs.rs metadata when running rustdoc

Closes #532

<details><summary>Outdated errors</summary>

I'm having trouble running the test suite, so I haven't yet added a test. My idea was to have a crate that only builds successfully when you read the metadata, but I'm not sure if that would work with the way the test suite is set up.

Current errors:
```
$ cargo test minicrater -- single_thread_small --ignored --test-threads 1
[2020-09-05T02:02:04Z INFO  rustwide::cmd] running `Command { std: "/home/joshua/src/rust/crater/work/cargo-home/bin/cargo" "+stable" "install" "lazy_static", kill_on_drop: false }`
[2020-09-05T02:02:04Z INFO  rustwide::cmd] [stderr]     Updating crates.io index
[2020-09-05T02:02:04Z INFO  rustwide::cmd] [stderr] error: specified package `lazy_static v1.4.0` has no binaries
[2020-09-05T02:02:04Z ERROR crater::utils] Permission denied (os error 13)
[2020-09-05T02:02:04Z ERROR crater::utils] note: run with `RUST_BACKTRACE=1` to display a backtrace.
[2020-09-05T02:02:04Z INFO  crater] command failed
', /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-0.10.1/src/assert.rs:154:13
```

</details>

Before merging, I need to publish the `docsrs-metadata` package to crates.io so crater doesn't depend on a git version.

r? `@pietroalbini` help
@bors
Copy link
Collaborator

bors commented Oct 19, 2020

⌛ Trying commit 4d1fd47 with merge d70e26a...

@bors
Copy link
Collaborator

bors commented Oct 19, 2020

💔 Test failed - checks-actions

@dylni
Copy link

dylni commented Oct 27, 2020

This might be a bad idea. Some of my crates have a line similar to this:
https://github.com/dylni/process_control/blob/4e5df8967054aff0c16184afa897025b6d8b1b35/Cargo.toml#L17

That --cfg enables nightly features, so IIUC, crater would fail these tests when testing a beta release.

@jyn514
Copy link
Member Author

jyn514 commented Oct 29, 2020

I think the plan was to set RUSTC_BOOTSTRAP so there wouldn't be spurious failures.

@jyn514
Copy link
Member Author

jyn514 commented Oct 29, 2020

I have not been able to get the tests to pass locally.

[2020-10-29T02:49:54Z INFO  rustwide::cmd] running `Command { std: "/home/joshua/src/rust/crater/work/cargo-home/bin/cargo" "+stable" "install" "lazy_static", kill_on_drop: false }`
[2020-10-29T02:49:54Z INFO  rustwide::cmd] [stderr]     Updating crates.io index
[2020-10-29T02:49:54Z INFO  rustwide::cmd] [stderr] error: specified package `lazy_static v1.4.0` has no binaries
[2020-10-29T02:49:54Z ERROR crater::utils] Permission denied (os error 13)
[2020-10-29T02:49:54Z ERROR crater::utils] note: run with `RUST_BACKTRACE=1` to display a backtrace.
[2020-10-29T02:49:54Z INFO  crater] command failed
', /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-0.10.1/src/assert.rs:154:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
FAILED

failures:

failures:
    minicrater::doc_small

@pietroalbini
Copy link
Member

Can you run it with RUST_BACKTRACE=1?

@jyn514
Copy link
Member Author

jyn514 commented Oct 29, 2020

Ugh, this was #545.

@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

But I think the question for me is basically - if these crates only build in an unstable configuration (e.g., on nightly or with RUSTC_BOOTSTRAP) then we don't really "care" about regressions in them. And every release of the crate is getting tested on nightly (and likely every pr, etc, to a similar extent). That implies that major crates likely have pretty good coverage as it is.

I think talking more about what our goals with rustdoc crater runs are and what we expect to catch (and what we know we can't) would be worthwhile. It's my impression that really only new ICEs or other hard failures will be caught - and those are very infrequent as newly detected by crater, in large part due to early testing by docs.rs I imagine...

Here is an example where crater runs are useful, and likely misleading because the metadata is ignored: rust-lang/cargo#10343 (comment)

@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

It's my impression that really only new ICEs or other hard failures will be caught - and those are very infrequent as newly detected by crater, in large part due to early testing by docs.rs I imagine...

This is bad, though. It means that the first time we notice regressions in rustdoc is after they're already impacting people publishing crates to the official registry. You could argue that docs.rs should be using a stable toolchain, and I don't disagree, but I don't see a way to make that possible without breaking basically every major crate ... rust-lang/docs.rs#506

@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

if these crates only build in an unstable configuration (e.g., on nightly or with RUSTC_BOOTSTRAP) then we don't really "care" about regressions in them.

I think you are underestimating how many crates use nightly features. Basically all major crates I know are using doc(cfg) on docs.rs (serde, regex, async-std, tokio, ...). The point is not to test that the nightly features don't change, but to make it possible to test these crates at all - for example, the regression in rust-lang/rust#73566 (comment) was not because of an unstable feature, but because rustdoc changed stable behavior, and we didn't notice because async-std only went through that code-path when passed --cfg docsrs.

@jyn514 jyn514 reopened this Apr 24, 2022
@Mark-Simulacrum
Copy link
Member

I think there's two use cases for crater: preventing regressions in general, and preventing regressions for stable users. For users on stable, they are not typically impacted by anything enabled by this PR, and indeed are rather the reverse: when I'm using a stable toolchain and running cargo doc, I'm building tokio etc without the docs.rs metadata enabled feature flags etc. That scenario wouldn't be tested if we landed this PR.

I agree that there is a major whole in our regression prevention story around docs.rs and crates not having a good way to work around nightly bugs impacting new releases (I guess manual rebuild requests). If we wanted to prevent ICEs and the like there, then we'd need a fairly frequent (i.e., more than new betas) crater run for nightly - this is feasible machine capacity wise I suspect, but poses a real challenge from a human triage hands perspective. (Certainly I don't have bandwidth to do that triage).

For crater runs that already happen on nightly (e.g. from PRs) it makes sense to me we'd potentially want to also run in this mode (in addition to the "bare" mode we typically do); in fact, I could see us just always doing that. (Duplicating each crate similar to compare-mode=nll in compiletest, though in this case with maybe lightweight detection of it not being needed due to lack of metadata?)

I think the tradeoff between testing builds that are only exercised by CI and docs.rs (i.e., in both cases surfacing issues to crate authors more so than users) and regular cargo doc builds (which would be covered by the current mode) is not clear. Doing both seems like a relatively easy out, and might not be hard to add - we already run multiple cargo invocations I think sometimes, so we'd just do that.

@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

I think there's two use cases for crater: preventing regressions in general, and preventing regressions for stable users.

👍 this is a good point. I like your idea of adding a separate mode for docs.rs metadata and only using that for nightly :) I can try to implement that.

@Mark-Simulacrum
Copy link
Member

Just to clarify, I think we should consider just always running both with and without docs.rs metadata - that is likely to be simpler and would likely cover both desires better. I'm not sure it'll be a 2x hit in terms of runtime either.

@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

I think we should consider just always running both with and without docs.rs metadata. I'm not sure it'll be a 2x hit in terms of runtime either.

I am confused. Is the idea to run both within the same run, so it reuses the build cache? I am not really sure how to implement that :( at least not in a way that doesn't break the reports.

@jyn514 jyn514 changed the title Read docs.rs metadata when running rustdoc Add a mode for reading docs.rs metadata when running rustdoc Apr 24, 2022
@Mark-Simulacrum
Copy link
Member

I think the way the code works it basically runs cargo doc today, I'm saying we would run it with the changes made in this PR and without the changes made in this PR.

@jyn514 jyn514 force-pushed the doc-runs branch 2 times, most recently from 5c215f8 to fbebafb Compare April 24, 2022 20:59
@jyn514
Copy link
Member Author

jyn514 commented Apr 24, 2022

I think the way the code works it basically runs cargo doc today, I'm saying we would run it with the changes made in this PR and without the changes made in this PR.

Ok, I implemented that. I didn't realize that crater could run cargo more than once, but I found in build_and_test that it already does so in other places.

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 24, 2022

📌 Commit fbebafb has been approved by Mark-Simulacrum

bors added a commit that referenced this pull request Apr 24, 2022
Add a mode for reading docs.rs metadata when running rustdoc

Closes #532

Before merging, I need to publish the `docsrs-metadata` package to crates.io so crater doesn't depend on a git version.
@bors
Copy link
Collaborator

bors commented Apr 24, 2022

⌛ Testing commit fbebafb with merge 56f441b...

@bors
Copy link
Collaborator

bors commented Apr 24, 2022

💔 Test failed - checks-actions

- Add tests for doc runs
- Only give an error when docs.rs feature is set in the test crate

  This allows distinguishing between 'any doc run' and 'doc run that uses
  docs.rs features'

- Set RUSTC_BOOTSTRAP for doc runs

  This is required for both docs.rs features and the flags passed by
  docsrs_metadata to cargo.

- Only use docs.rs features for libraries

  `docsrs_metadata` unconditionally passes `--lib` to cargo, which gives a hard error when no
  library is present. This also required changing the setup in `runner/tests` to pass through the
  full package metadata to all test runners.
@jyn514
Copy link
Member Author

jyn514 commented Apr 25, 2022

Tests should hopefully be fixed - I had to update the reports for the full build to include the new crate.

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 25, 2022

📌 Commit 339c2ed has been approved by Mark-Simulacrum

@bors
Copy link
Collaborator

bors commented Apr 25, 2022

⌛ Testing commit 339c2ed with merge 4500cef...

@bors
Copy link
Collaborator

bors commented Apr 25, 2022

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 4500cef to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Crater should read the same metadata as docs.rs for doc runs
6 participants