Aaron Hill
Aaron Hill
Currently, we only check crates in the workspace for a check-only build: https://github.com/rust-lang/crater/blob/dcc54566d5ec82cabca435c0145cbd06f32d3602/src/runner/test.rs#L302-L308 However, we do not pass `--tests`, which can cause us to miss some regressions. See https://github.com/rust-lang/rust/issues/77789#issuecomment-706600489
In several different Crater runs, I've seen `pin-project-internal` jobs get killed via SIGKILL. I suspect that this is due to the build using too much memory and getting killed by...
When `data/github.csv` is read, only repositories with both a `Cargo.toml` and a `Cargo.lock` are tested: https://github.com/rust-lang/crater/blob/dcc54566d5ec82cabca435c0145cbd06f32d3602/src/crates/sources/github.rs#L44-L47 Based on the comment, it looks like the intention was to test repositories with...
It's common to write `@bors try @rust-timer queue` on a pull request, which will cause both bors and rust-timer to run commands. However, craterbot does not support this style of...
The estimated time assumes that a job runs continuously from start to end. This can cause results like this: 
The experiment page https://crater.rust-lang.org/ex/pr-73345 currenty looks like this:  The list of `build-fail` errors actually continues on below the fold. When I implemented this feature in https://github.com/rust-lang/crater/pull/499, it displayed counts...
This would be most useful in conjunction with https://github.com/rust-lang/crater/issues/440. With the current overhead of Miri, I suspect that a full run on crates.io could literally take years to complete :smile:
It's often useful to distinguish compiler ICEs, which are bug by definition, from compiler errors, which are usually not bugs. This is especially true when performing rustdoc crater runs, as...
This mode would make it easy to see how the total number of dependencies of a crate changes over time, as its dependencies add or remove dependencies of their own.
Rust recently added a Tier-3 `x86_64-unknown-none` target: https://github.com/rust-lang/rust/pull/89062 I believe it should be possible to use this target instead of the custom `x86_64-blog_os.json` target. It's designed to support bare-metal x86_64...