rust-lang / cargo-bisect-rustc Goto Github PK

View Code? Open in Web Editor NEW

173.0 12.0 55.0 1.9 MB

Bisects rustc, either nightlies or CI artifacts

Home Page: https://rust-lang.github.io/cargo-bisect-rustc/

License: Apache License 2.0

Rust 100.00%

cargo-bisect-rustc's Introduction

Cargo Bisection

This tool bisects either Rust nightlies or CI artifacts.

Documentation

To run the documentation book locally, install mdBook:

cd guide
mdbook serve # launch a local server to allow you to easily see and update changes you make
mdbook build # build the book HTML

License

Licensed under either of

Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

cargo-bisect-rustc's People

Contributors

Stargazers

Watchers

cargo-bisect-rustc's Issues

expanding a commit should include more info

(spawned off of https://github.com/rust-lang/cargo-bisect-rustc/pull/63/files#r387222802 )

Expanding a commit from a given sha prefix should include more info.

Most notably, the summary message associated with the commit could be included in the structure you get from expanding it.

find MSRV

i'd like to use this tool to find the minimum supported rust version for my crate. Is that a supported use-case?

This will take a long time to run, as i don't know at what point features i'm relying on were added to the compiler.

cargo bisect seems to default to 2 days at a time, which is fine if you know the regression was fairly recent.

Is this configurable? is there some configuration i can use to make the bisection time delta grow (exponentially) with every iteration?

Can't find commit range for nightly toolchain

cargo-bisect-rustc is unable to find the commit range for a nightly toolchain, if the git commit hash file of the previous nightly returns 404.

If cargo-bisect-rustc is trying to find the commit range for nightly-2020-09-02, it will step one day back (2020-09-01) but this nightly doesn't have a statically hosted git commit hash and thus cargo-bisect-rustc fails.

It should try to step back more versions until it finds one that doesn't return 404 (2020-08-29 in this case)

error: unknown crate type: `proc-macro`

On a trivial project created by cargo new (and removing the edition from Cargo.toml):

$ cargo bisect-rustc --start 2016-06-16 --end 2016-10-03 --prompt
checking nightly-2016-06-16
std for x86_64-unknown-linux-gnu: 58.89 MB / 58.89 MB [=======================================================================================] 100.00 % 11.15 MB/s
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 101)
--- stderr
error: unknown crate type: `proc-macro`



nightly-2016-06-16 finished with exit code Some(101).
please select an action to take:
uninstalling nightly-2016-06-16
the --start nightly has the regression

If rustup does not exist, error is very opaque

Outputs a simple "No such file or directory (os error 2)".

Allow to switch to ci-based bisect

For Firefox, we have something similar to bisect-rustc, called mozregression.

mozregression allows to find regressions between nightlies, and between CI builds, just like bisect-rustc, but also allows to switch from one to the other (I don't remember if it does so automatically, asks, or relies on being re-invoked).

Anyways, at the very minimum, when finishing up bisecting with nightlies, if the last failed and the first success were printed out, including their corresponding git commits, one could then re-run the command to find the regression between those commits.

`--test-dir` should default to `.`

As titled. Running cargo bisect-rustc without any arguments should find regression using the current project.

Panics with 'index out of bounds' if `--end` < `--start`

I guess it would be nice to check for validity of date ordering and abort early with a more helpful message.

RUST_BACKTRACE=1 cargo-bisect-rustc --start=2018-09-01 --end=2018-01-01
checking nightly-2018-09-01
std for x86_64-apple-darwin: 47.25 MB / 47.25 MB [==============================================] 100.00 % 1.10 MB/s  uninstalling nightly-2018-09-01
verifying the start of the range does not reproduce the regression
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/least_satisfying.rs:17:85
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic_bounds_check
   9: <alloc::collections::btree::map::Entry<'a, K, V>>::or_insert_with
  10: cargo_bisect_rustc::least_satisfying::least_satisfying
  11: cargo_bisect_rustc::run
  12: cargo_bisect_rustc::main
  13: std::rt::lang_start::{{closure}}
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start_internal
  17: main

Future date requests attempt download + install of nightly

A future date typo leads to an attempt to download and install the nightly and presents the error "could not find nightly [DATE]". It will never be there... :) A date validation to prevent the GET request attempt and a more informative error message would be helpful.

$ cargo bisect-rustc --start=2020-10-10
installing nightly-2020-10-10
uninstalling nightly-2020-10-10
*** unable to install nightly-2020-10-10. roll back one day and try again...
ERROR: could not find nightly-2020-10-10

Nightly testing start date test is repeated when --start is defined on command line

Test source with regression from blog post:

pub struct Slice<'a, T>(&'a [T]);

impl<'a, T: 'a> Slice<'a, T> {
    pub const EMPTY: Self = Slice ({
        let v: &[T] = &[];
        v
    });
}

fn main() {
    let s = Slice(&[1, 2]);
    assert!(s.0 != Slice::EMPTY.0);
}

Test:

$ cargo bisect-rustc --start=2019-09-20 --end=2019-10-02

checking nightly-2019-09-20
std for x86_64-apple-darwin: 172.68 MB / 172.68 MB [==========================] 100.00 % 18.01 MB/s uninstalling nightly-2019-09-20
verifying the start of the range does not reproduce the regression
std for x86_64-apple-darwin: 172.68 MB / 172.68 MB [==========================] 100.00 % 18.07 MB/s uninstalling nightly-2019-09-20
tested nightly-2019-09-20, got No
confirmed the start of the range does not reproduce the regression
verifying the end of the range reproduces the regression
std for x86_64-apple-darwin: 171.05 MB / 171.05 MB [==========================] 100.00 % 17.30 MB/s uninstalling nightly-2019-10-02
tested nightly-2019-10-02, got Yes
confirmed the end of the range reproduces the regression

[ ... snip ... ]

The 2020-09-20 nightly is installed, tested, & uninstalled twice. The first test is in the bisect_nightlies function. The second test is in the least_satisfying function.

It looks like the duplication happens because the bisect commit testing does rely on the start range test in least_satisfying.

--start / --end don't seem to work

I tried passing various dates for --start/--end, but all I got was a search between the last two nightlies ("nightly-2018-03-21 through nightly-2018-03-22" as of writing).

Relatedly, it would be nice to be able to pass rust versions instead of nightly dates.

Generated toolchains not working

So I recently had to reinstall and the generated toolchains by cargo-bisect-rustc are not working. It feels has if they are not been found so the stable (my default and only other toolchain I have right now) is used instead.

Output of a recent run:

 > cargo bisect-rustc --preserve --prompt --end 2020-05-08 -- version
installing nightly-2020-05-08
std for x86_64-apple-darwin: 14.50 MB / 14.50 MB [========================================================================] 100.00 % 6.26 MB/s testing...
cargo 1.45.0 (744bd1fbb 2020-06-15)

Instead if I install the nightly, link it, and run the same command it works as expected:

 > rustup install nightly-2020-05-08
...
 > rustup toolchain link bisector-nightly-2020-05-08-x86_64-apple-darwin ~/.rustup/toolchains/nightly-2020-05-08-x86_64-apple-darwin
...
 > cargo bisect-rustc --preserve --prompt --end 2020-05-08 -- version
installing nightly-2020-05-08
testing...
cargo 1.45.0-nightly (f534844c2 2020-05-06)

Versions:

 > cargo bisect-rustc --version
cargo-bisect-rustc 0.5.2

 > rustup --version
rustup 1.22.1 (b01adbbc3 2020-07-08)

Mention `--with-cargo` in tutorial or make it a default

Without correct version of cargo any version of rustc that is older than few weeks will produce random build errors which will be counted as "regression found" by default.

It is pretty confusing when bisect-rustc tells that revision xyz produces an error and silently stops bisecting correctly, while cargo +xyz build doesn't produce any error when run explicitly.

Panics with "~" in test-dir

--test-dir=$HOME/test/crate works, --test-dir=~/test/crate panics:

thread 'main' panicked at 'failed to run "cargo" "+bisector-nightly-2019-01-01-x86_64-apple-darwin" "build": Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:538:17

Missing --end definition with SHA testing leads to error under --access=github approach

Related #71

#71 fixes this bug when the Rust repository is cloned locally. When the GitHub API is used with the --access=github argument, a --start definition is defined without an --end definition, and the request starts execution at the commit SHA level, the error is still present:

$ cargo bisect-rustc --start=488381ce9ef0ceabe83b73127c659e5d38137df0 --access=github
bisecting ci builds
starting at 488381ce9ef0ceabe83b73127c659e5d38137df0, ending at origin/master
adding local env GITHUB_TOKEN value to headers in github query
ERROR: error decoding response body: missing field `commit` at line 1 column 141

Test source from the Inside Rust tutorial.

Ctrl-c should clean-up temporary files

When hitting Ctrl-C when bisect-rustc is working, files may be left in a temporary location. They should be automatically cleaned up.

panic, when selecting `mark baseline` two times

# cargo new foo
# cd foo/src/
# env RUST_BACKTRACE=1 cargo-bisect-rustc --test-dir .

selecting mark baseline in both cases

checking nightly-2018-05-25
std for x86_64-unknown-linux-gnu: 51.11 MB / 51.11 MB [===========================================================================================================] 100.00 % 2.73 MB/s      Finished dev [unoptimized + debuginfo] target(s) in 0.03s
uninstalling nightly-2018-05-25


nightly-2018-05-25 finished with exit code Some(0).
please select an action to take:
verifying the start of the range does not reproduce the regression
std for x86_64-unknown-linux-gnu: 51.11 MB / 51.11 MB [===========================================================================================================] 100.00 % 2.72 MB/s      Finished dev [unoptimized + debuginfo] target(s) in 0.00s
uninstalling nightly-2018-05-25


nightly-2018-05-25 finished with exit code Some(0).
please select an action to take:
uninstalling nightly-2018-05-25
tested nightly-2018-05-25, got No
confirmed the start of the range does not reproduce the regression
verifying the end of the range reproduces the regression
thread 'main' panicked at 'the end of the range to test must reproduce the regression', src/least_satisfying.rs:34:14
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:463
   5: std::panicking::begin_panic
   6: cargo_bisect_rustc::least_satisfying::least_satisfying
   7: cargo_bisect_rustc::run
   8: cargo_bisect_rustc::main
   9: std::rt::lang_start::{{closure}}
  10: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  11: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  12: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:374
             at libstd/rt.rs:58
  13: main
  14: __libc_start_main
  15: _start

Add timeout

To bisect hangs.

macOS Catalina error trying to install

Hi, I'm using macOS Catalina 10.15.1 and I get an error when doing cargo install cargo-bisect-rustc

Error and details

error: failed to run custom build command for `libssh2-sys v0.2.13`
process didn't exit successfully: `/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-0b6b9ae53fb629dd/build-script-build` (exit code: 1)
--- stdout
cargo:include=/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/include
cargo:root=/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = Some("-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/usr/local/opt/openssl/include/" "-I/usr/local/include" "-I/usr/local/opt/expat/include" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/include" "-I" "libssh2/src" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build" "-I" "/usr/local/opt/openssl/include" "-fvisibility=hidden" "-DHAVE_LONGLONG" "-DHAVE_SNPRINTF" "-DHAVE_UNISTD_H" "-DHAVE_INTTYPES_H" "-DHAVE_STDLIB_H" "-DHAVE_SYS_SELECT_H" "-DHAVE_SYS_SOCKET_H" "-DHAVE_SYS_IOCTL_H" "-DHAVE_SYS_TIME_H" "-DHAVE_SYS_UN_H" "-DHAVE_O_NONBLOCK" "-DLIBSSH2_OPENSSL" "-DHAVE_LIBCRYPT32" "-DHAVE_EVP_AES_128_CTR" "-DHAVE_POLL" "-DLIBSSH2_DH_GEX_NEW" "-DLIBSSH2_HAVE_ZLIB" "-o" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build/libssh2/src/agent.o" "-c" "libssh2/src/agent.c"
exit code: 0
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/usr/local/opt/openssl/include/" "-I/usr/local/include" "-I/usr/local/opt/expat/include" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/include" "-I" "libssh2/src" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build" "-I" "/usr/local/opt/openssl/include" "-fvisibility=hidden" "-DHAVE_LONGLONG" "-DHAVE_SNPRINTF" "-DHAVE_UNISTD_H" "-DHAVE_INTTYPES_H" "-DHAVE_STDLIB_H" "-DHAVE_SYS_SELECT_H" "-DHAVE_SYS_SOCKET_H" "-DHAVE_SYS_IOCTL_H" "-DHAVE_SYS_TIME_H" "-DHAVE_SYS_UN_H" "-DHAVE_O_NONBLOCK" "-DLIBSSH2_OPENSSL" "-DHAVE_LIBCRYPT32" "-DHAVE_EVP_AES_128_CTR" "-DHAVE_POLL" "-DLIBSSH2_DH_GEX_NEW" "-DLIBSSH2_HAVE_ZLIB" "-o" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build/libssh2/src/bcrypt_pbkdf.o" "-c" "libssh2/src/bcrypt_pbkdf.c"
exit code: 0
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/usr/local/opt/openssl/include/" "-I/usr/local/include" "-I/usr/local/opt/expat/include" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/include" "-I" "libssh2/src" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build" "-I" "/usr/local/opt/openssl/include" "-fvisibility=hidden" "-DHAVE_LONGLONG" "-DHAVE_SNPRINTF" "-DHAVE_UNISTD_H" "-DHAVE_INTTYPES_H" "-DHAVE_STDLIB_H" "-DHAVE_SYS_SELECT_H" "-DHAVE_SYS_SOCKET_H" "-DHAVE_SYS_IOCTL_H" "-DHAVE_SYS_TIME_H" "-DHAVE_SYS_UN_H" "-DHAVE_O_NONBLOCK" "-DLIBSSH2_OPENSSL" "-DHAVE_LIBCRYPT32" "-DHAVE_EVP_AES_128_CTR" "-DHAVE_POLL" "-DLIBSSH2_DH_GEX_NEW" "-DLIBSSH2_HAVE_ZLIB" "-o" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-install39FpUd/release/build/libssh2-sys-5a90add64952b847/out/build/libssh2/src/blowfish.o" "-c" "libssh2/src/blowfish.c"
cargo:warning=In file included from libssh2/src/blowfish.c:55:
cargo:warning=libssh2/src/blf.h:52:9: error: unknown type name 'uint32_t'
cargo:warning=        uint32_t S[4][256];     /* S-Boxes */
cargo:warning=        ^
cargo:warning=libssh2/src/blf.h:53:9: error: unknown type name 'uint32_t'
cargo:warning=        uint32_t P[BLF_N + 2];  /* Subkeys */
cargo:warning=        ^
cargo:warning=libssh2/src/blf.h:62:35: error: unknown type name 'uint32_t'
cargo:warning=void Blowfish_encipher(blf_ctx *, uint32_t *, uint32_t *);
cargo:warning=                                  ^
cargo:warning=libssh2/src/blf.h:62:47: error: unknown type name 'uint32_t'
cargo:warning=void Blowfish_encipher(blf_ctx *, uint32_t *, uint32_t *);
cargo:warning=                                              ^
cargo:warning=libssh2/src/blf.h:63:35: error: unknown type name 'uint32_t'
cargo:warning=void Blowfish_decipher(blf_ctx *, uint32_t *, uint32_t *);
cargo:warning=                                  ^
cargo:warning=libssh2/src/blf.h:63:47: error: unknown type name 'uint32_t'
cargo:warning=void Blowfish_decipher(blf_ctx *, uint32_t *, uint32_t *);
cargo:warning=                                              ^
cargo:warning=libssh2/src/blf.h:65:45: error: unknown type name 'uint8_t'
cargo:warning=void Blowfish_expand0state(blf_ctx *, const uint8_t *, uint16_t);
cargo:warning=                                            ^
cargo:warning=libssh2/src/blf.h:65:56: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void Blowfish_expand0state(blf_ctx *, const uint8_t *, uint16_t);
cargo:warning=                                                       ^
cargo:warning=libssh2/src/blf.h:67:19: error: unknown type name 'uint8_t'
cargo:warning=(blf_ctx *, const uint8_t *, uint16_t, const uint8_t *, uint16_t);
cargo:warning=                  ^
cargo:warning=libssh2/src/blf.h:67:30: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=(blf_ctx *, const uint8_t *, uint16_t, const uint8_t *, uint16_t);
cargo:warning=                             ^
cargo:warning=libssh2/src/blf.h:67:46: error: unknown type name 'uint8_t'
cargo:warning=(blf_ctx *, const uint8_t *, uint16_t, const uint8_t *, uint16_t);
cargo:warning=                                             ^
cargo:warning=libssh2/src/blf.h:67:57: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=(blf_ctx *, const uint8_t *, uint16_t, const uint8_t *, uint16_t);
cargo:warning=                                                        ^
cargo:warning=libssh2/src/blf.h:67:57: error: redefinition of parameter 'uint16_t'
cargo:warning=libssh2/src/blf.h:67:30: note: previous declaration is here
cargo:warning=(blf_ctx *, const uint8_t *, uint16_t, const uint8_t *, uint16_t);
cargo:warning=                             ^
cargo:warning=libssh2/src/blf.h:71:31: error: unknown type name 'uint8_t'
cargo:warning=void blf_key(blf_ctx *, const uint8_t *, uint16_t);
cargo:warning=                              ^
cargo:warning=libssh2/src/blf.h:71:42: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_key(blf_ctx *, const uint8_t *, uint16_t);
cargo:warning=                                         ^
cargo:warning=libssh2/src/blf.h:72:25: error: unknown type name 'uint32_t'
cargo:warning=void blf_enc(blf_ctx *, uint32_t *, uint16_t);
cargo:warning=                        ^
cargo:warning=libssh2/src/blf.h:72:37: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_enc(blf_ctx *, uint32_t *, uint16_t);
cargo:warning=                                    ^
cargo:warning=libssh2/src/blf.h:73:25: error: unknown type name 'uint32_t'
cargo:warning=void blf_dec(blf_ctx *, uint32_t *, uint16_t);
cargo:warning=                        ^
cargo:warning=libssh2/src/blf.h:73:37: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_dec(blf_ctx *, uint32_t *, uint16_t);
cargo:warning=                                    ^
cargo:warning=libssh2/src/blf.h:75:33: error: unknown type name 'uint8_t'
cargo:warning=void blf_ecb_encrypt(blf_ctx *, uint8_t *, uint32_t);
cargo:warning=                                ^
cargo:warning=libssh2/src/blf.h:75:44: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_ecb_encrypt(blf_ctx *, uint8_t *, uint32_t);
cargo:warning=                                           ^
cargo:warning=libssh2/src/blf.h:76:33: error: unknown type name 'uint8_t'
cargo:warning=void blf_ecb_decrypt(blf_ctx *, uint8_t *, uint32_t);
cargo:warning=                                ^
cargo:warning=libssh2/src/blf.h:76:44: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_ecb_decrypt(blf_ctx *, uint8_t *, uint32_t);
cargo:warning=                                           ^
cargo:warning=libssh2/src/blf.h:78:33: error: unknown type name 'uint8_t'
cargo:warning=void blf_cbc_encrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                ^
cargo:warning=libssh2/src/blf.h:78:44: error: unknown type name 'uint8_t'
cargo:warning=void blf_cbc_encrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                           ^
cargo:warning=libssh2/src/blf.h:78:55: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_cbc_encrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                                      ^
cargo:warning=libssh2/src/blf.h:79:33: error: unknown type name 'uint8_t'
cargo:warning=void blf_cbc_decrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                ^
cargo:warning=libssh2/src/blf.h:79:44: error: unknown type name 'uint8_t'
cargo:warning=void blf_cbc_decrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                           ^
cargo:warning=libssh2/src/blf.h:79:55: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cargo:warning=void blf_cbc_decrypt(blf_ctx *, uint8_t *, uint8_t *, uint32_t);
cargo:warning=                                                      ^
cargo:warning=fatal error: too many errors emitted, stopping now [-ferror-limit=]
cargo:warning=10 warnings and 20 errors generated.
exit code: 1

--- stderr
fatal: not a git repository (or any of the parent directories): .git


error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/usr/local/opt/openssl/include/" "-I/usr/local/include" "-I/usr/local/opt/expat/include" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-installQEtGQK/release/build/libssh2-sys-3c3939e7dfa247cb/out/include" "-I" "libssh2/src" "-I" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-installQEtGQK/release/build/libssh2-sys-3c3939e7dfa247cb/out/build" "-I" "/usr/local/opt/[email protected]/include" "-fvisibility=hidden" "-DHAVE_LONGLONG" "-DHAVE_SNPRINTF" "-DHAVE_UNISTD_H" "-DHAVE_INTTYPES_H" "-DHAVE_STDLIB_H" "-DHAVE_SYS_SELECT_H" "-DHAVE_SYS_SOCKET_H" "-DHAVE_SYS_IOCTL_H" "-DHAVE_SYS_TIME_H" "-DHAVE_SYS_UN_H" "-DHAVE_O_NONBLOCK" "-DLIBSSH2_OPENSSL" "-DHAVE_LIBCRYPT32" "-DHAVE_EVP_AES_128_CTR" "-DHAVE_POLL" "-DLIBSSH2_DH_GEX_NEW" "-DLIBSSH2_HAVE_ZLIB" "-o" "/var/folders/56/pj8jcnbn2zb9rlr897733h0m0000gn/T/cargo-installQEtGQK/release/build/libssh2-sys-3c3939e7dfa247cb/out/build/libssh2/src/blowfish.o" "-c" "libssh2/src/blowfish.c" with args "cc" did not execute successfully (status code exit code: 1).

Any ideas on how to fix it?

EDIT: Including other relevant versions

~> rustc --version
rustc 1.41.0 (5e1a79984 2020-01-27)

~> cargo --version
cargo 1.41.0 (626f0f40e 2019-12-03)

~> cc --version
Apple clang version 11.0.0 (clang-1100.0.33.12)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Bisect rollups

Is it possible it could figure out which PR in a roll-up was responsible?
That really would be the ICEing on the cake.

Searched date range misreported

https://github.com/bjorn3/cargo-bisect-rustc-bot-jobs/runs/650650115#step:6:107

I told cargo bisect-rustc to bisect up to 2020-04-25 and it did that, but in the final report it said that it bisected up to 2020-04-10

Nightly can be checked thrice in certain cases

$ cargo-bisect-rustc --end=2020-05-09
installing nightly-2020-05-09
RESULT: nightly-2020-05-09, ===> Yes
uninstalling nightly-2020-05-09

installing nightly-2020-05-07
RESULT: nightly-2020-05-07, ===> Yes
uninstalling nightly-2020-05-07

installing nightly-2020-05-05
RESULT: nightly-2020-05-05, ===> Yes
uninstalling nightly-2020-05-05

installing nightly-2020-05-03
RESULT: nightly-2020-05-03, ===> No
uninstalling nightly-2020-05-03

installing nightly-2020-05-05
RESULT: nightly-2020-05-05, ===> Yes
uninstalling nightly-2020-05-05

installing nightly-2020-05-04
RESULT: nightly-2020-05-04, ===> No
uninstalling nightly-2020-05-04

searched toolchains nightly-2020-05-03 through nightly-2020-05-05
installing nightly-2020-05-05
uninstalling nightly-2020-05-05


********************************************************************************
Regression in nightly-2020-05-05
********************************************************************************

As you can see, 2020-05-05 is downloaded and tested thrice. Is that necessary?

Commit testing fails after nightly testing when there is no nightly at the begin date defined during nightly tests

After identifying a rustc regression in a March 2019 nightly with a shell script that executes rustc directly, the tool fails and exits with a non-zero exit status code during the attempt to bisect by commits with the following error:

checking nightly-2019-01-01
std for x86_64-unknown-linux-gnu: 56.94 MB / 56.94 MB [==========================================] 100.00 % 4.74 MB/s uninstalling nightly-2019-01-01
verifying the start of the range does not reproduce the regression
std for x86_64-unknown-linux-gnu: 56.94 MB / 56.94 MB [==========================================] 100.00 % 2.96 MB/s uninstalling nightly-2019-01-01
tested nightly-2019-01-01, got No
confirmed the start of the range does not reproduce the regression
verifying the end of the range reproduces the regression
std for x86_64-unknown-linux-gnu: 17.53 MB / 17.53 MB [==========================================] 100.00 % 4.07 MB/s uninstalling nightly-2020-02-01
tested nightly-2020-02-01, got Yes
confirmed the end of the range reproduces the regression
std for x86_64-unknown-linux-gnu: 170.27 MB / 170.27 MB [========================================] 100.00 % 4.98 MB/s uninstalling nightly-2019-07-18
tested nightly-2019-07-18, got Yes
uninstalling nightly-2019-04-10
failed to install nightly-2019-04-10: NotFound { url: "https://static.rust-lang.org/dist/2019-04-10/rustc-nightly-x86_64-unknown-linux-gnu.tar.gz", spec: Nightly { date: 2019-04-10Z } }
std for x86_64-unknown-linux-gnu: 59.01 MB / 59.01 MB [==========================================] 100.00 % 4.16 MB/s uninstalling nightly-2019-04-09
tested nightly-2019-04-09, got Yes
std for x86_64-unknown-linux-gnu: 59.27 MB / 59.27 MB [==========================================] 100.00 % 9.24 MB/s uninstalling nightly-2019-04-11
tested nightly-2019-04-11, got Yes
std for x86_64-unknown-linux-gnu: 55.88 MB / 55.88 MB [==========================================] 100.00 % 7.68 MB/s uninstalling nightly-2019-02-19
tested nightly-2019-02-19, got No
std for x86_64-unknown-linux-gnu: 57.67 MB / 57.67 MB [=========================================] 100.00 % 11.12 MB/s uninstalling nightly-2019-03-15
tested nightly-2019-03-15, got Yes
std for x86_64-unknown-linux-gnu: 56.39 MB / 56.39 MB [==========================================] 100.00 % 4.80 MB/s uninstalling nightly-2019-03-03
tested nightly-2019-03-03, got No
std for x86_64-unknown-linux-gnu: 58.08 MB / 58.08 MB [==========================================] 100.00 % 5.39 MB/s uninstalling nightly-2019-03-09
tested nightly-2019-03-09, got Yes
std for x86_64-unknown-linux-gnu: 56.62 MB / 56.62 MB [==========================================] 100.00 % 4.92 MB/s uninstalling nightly-2019-03-06
tested nightly-2019-03-06, got No
uninstalling nightly-2019-03-07
failed to install nightly-2019-03-07: NotFound { url: "https://static.rust-lang.org/dist/2019-03-07/rustc-nightly-x86_64-unknown-linux-gnu.tar.gz", spec: Nightly { date: 2019-03-07Z } }
std for x86_64-unknown-linux-gnu: 56.47 MB / 56.47 MB [==========================================] 100.00 % 2.73 MB/s uninstalling nightly-2019-03-08
tested nightly-2019-03-08, got Yes
searched toolchains nightly-2019-01-01 through nightly-2020-02-01
regression in nightly-2019-03-08
fetching https://static.rust-lang.org/dist/2019-03-08/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2019-03-08: 40 B / 40 B [=====================================================] 100.00 % 489.60 KB/s converted 2019-03-08 to 88f755f8a84df1d9e6b17cf10c96ae8b93481b2e
fetching https://static.rust-lang.org/dist/2019-03-07/channel-rust-nightly-git-commit-hash.txt
Tarball not found at https://static.rust-lang.org/dist/2019-03-07/channel-rust-nightly-git-commit-hash.txt

When I enter the URL manually, there is a git commit hash at https://static.rust-lang.org/dist/2019-03-06/channel-rust-nightly-git-commit-hash.txt and https://static.rust-lang.org/dist/2019-03-08/channel-rust-nightly-git-commit-hash.txt, but not at https://static.rust-lang.org/dist/2019-03-07/channel-rust-nightly-git-commit-hash.txt.

It looks like we need to maintain information about missing nightlies during the nightly test phase so that we can step back to the next most recent nightly for the commit test range definition.

use without cargo

My problem rust-lang/rust#50993 cannot be reproduced while using cargo, but only rustc directly.

There is (afaik) no option to invoke rustc directly without cargo at all.
How can this be achieved?

cargo rustc -- --emit asm --crate-type dylib --target thumbv7em-none-eabihf
   Compiling peter v0.1.0 (file:///tmp/tmp.PwRrFAXQE6/peter)
warning: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf`

    Finished dev [unoptimized + debuginfo] target(s) in 0.51s
op@VBOX /t/t/peter> rustc --emit asm --crate-type dylib --target thumbv7em-none-eabihf src/lib.rs 
warning: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf`

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.28.0-nightly (cb20f68d0 2018-05-21) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type dylib

Cargo emits "error: Unrecognized option: 'json'" error beginning ~ 07/2019, consider option to bisect rustc directly without Cargo

From the conversation of a cargo-bisect-rustc ICE analysis in rust-lang/rust#69096 (comment) where the error message error: Unrecognized option: 'json' occurred as of the 2019-07-30 nightly.

@eddyb said:

That suggests that you're using a Cargo too new or somehow back-compat logic was removed (or never present?) in Cargo (not sure what our policy is).

You need an older Cargo to go back past the addition of --json.

But also it would be nice if Cargo didn't need to be involved in the bisection process, because it IMO unnecessarily complicates it.

cargo 1.41.0 (626f0f40e 2019-12-03)
release: 1.41.0
commit-hash: 626f0f40efd32e6b3dbade50cd53fdfaa08446ba
commit-date: 2019-12-03

cargo 1.43.0-nightly (3c53211c3 2020-02-07)
release: 1.43.0
commit-hash: 3c53211c3d7fee4f430f170115af5baad17a3da9
commit-date: 2020-02-07

Potentially use rustc-artifacts crate

https://docs.rs/rustc-artifacts/0.2.0/rustc_artifacts/fn.master_commits.html provides access to bors commit data that doesn't depend on the GitHub API. It provides less information than we might want today, but I would be willing to expand that (I'm the owner of the crate).

That crate currently uses a new triagebot API that lists bors commits made in the last 168 days, currently with just the sha, parent sha, and timestamp of the commit.

That would mean that we can run bisection entirely without the GITHUB_TOKEN or a local rust repository clone, and then use the GitHub API solely to lookup the commit details (if desired).

why RUST_SRC_REPO needs to know at compile time ?

cargo-bisect-rustc/src/git.rs

Line 11 in 843b96e

const RUST_SRC_REPO: Option<&str> = option_env!("RUST_SRC_REPO");

If I build cargo-bisect-rustc and copy it to another computer with different directory to rustc,
does it make me slowly re-clone rustc ?

confusing experience with cargo args

I wanted to bisect with a feature enabled in my project. I used this command:

cargo bisect-rustc -- --features=c_avx512

Of course, that's a mistake. I didn't realize that I should have -- build --features=c_avx512 instead of -- --features=c_avx512. However, the mistake was very non-obvious. cargo bisect-rustc just kept downloading older and older nightly versions. Only after I eventually added -vv did I get to see the very helpful error:

Found argument '--features' which wasn't expected, or isn't valid in this context

USAGE:
    cargo [OPTIONS] [SUBCOMMAND]

This is probably going to be a common experience for other folks new to the tool. Maybe it would be better to print all errors by default? Or somehow provide a discoverable fix for issues like the above?

Download/Install fails moving from tempdir to destination

On Unix system, it is very customary for the temporary directory (/tmp) to not live in the same filesystem as the home directory. So the fs::rename in Toolchain::install fails with "Invalid cross-device link (os error 18)".

nightly for `rustup default` breaks cargo-bisectc-rustc when start..end range overaps current nightly

This is an issue to track the problem described on PR #45

Demonstration:

Here is a file that does not expose any regression in rustc (or cargo):

src/main.rs:

fn main() {
    println!("Hello world");
}

Here is a transcript of my interactions in the shell (note the use of -v -v to observe the actual runs and their output):

% rustup default
nightly-x86_64-apple-darwin (default)
% rustc --version
rustc 1.43.0-nightly (e620d0f33 2020-02-18)
% cargo-bisect-rustc --start 2020-02-17 -v -v
checking nightly-2020-02-17
std for x86_64-apple-darwin: 16.47 MB / 16.47 MB [=========] 100.00 % 4.91 MB/s    Compiling bisect-area v0.1.0 (/Users/felixklock/Dev/Mozilla/bisect-area)
    Finished dev [unoptimized + debuginfo] target(s) in 1.03s
uninstalling nightly-2020-02-17
verifying the start of the range does not reproduce the regression
std for x86_64-apple-darwin: 16.47 MB / 16.47 MB [=========] 100.00 % 4.57 MB/s    Compiling bisect-area v0.1.0 (/Users/felixklock/Dev/Mozilla/bisect-area)
    Finished dev [unoptimized + debuginfo] target(s) in 0.97s
uninstalling nightly-2020-02-17
tested nightly-2020-02-17, got No
confirmed the start of the range does not reproduce the regression
verifying the end of the range reproduces the regression
error: toolchain 'bisector-nightly-2020-02-18-x86_64-apple-darwin' is not installed
tested nightly-2020-02-18, got Yes
confirmed the end of the range reproduces the regression
searched toolchains nightly-2020-02-17 through nightly-2020-02-18
error: toolchain 'bisector-nightly-2020-02-18-x86_64-apple-darwin' is not installed
regression in nightly-2020-02-18
fetching https://static.rust-lang.org/dist/2020-02-18/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2020-02-18: 40 B / 40 B [================] 100.00 % 66.08 KB/s converted 2020-02-18 to 0176a9eef845e7421b7e2f7ef015333a41a7c027
fetching https://static.rust-lang.org/dist/2020-02-17/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2020-02-17: 40 B / 40 B [===============] 100.00 % 105.10 KB/s converted 2020-02-17 to 5e7af4669f80e5f682141f050193ab679afdb4b1
looking for regression commit between 2020-02-18 and 2020-02-17

This is the problematic part of the transcript:

verifying the end of the range reproduces the regression
error: toolchain 'bisector-nightly-2020-02-18-x86_64-apple-darwin' is not installed
tested nightly-2020-02-18, got Yes

That is, a internal bug in cargo-bisect-rustc leads to a problem with a particular rustc +{} ... invocation (where it substitutes bisector-nightly-2020-02-18 for {}) and then cargo-bisect-rustc treats the failure of that invocation as a regression, rather than a problem external to rustc/cargo.

Does not work on systems without outdated openssl version(s)

On my system openssl < 1.0.1 is not available and thus the build fails due to sfackler/rust-openssl#987

--by-commit fails

--by-commit fails, as of writing, with:

expected to start with 927c55d86b0be44337f37cf5b0a76fb8ba86e06c, but started with 565907fefb2a69c279b59bffa84c6d30129cafe9

Flag to check for internal compiler errors

It would be nice as a convenience if this could provide an --ice flag to check specifically for internal compiler errors rather than any error.

Option to use a script?

Is there an option to use a script like the old bisect-rust?

My use case was to test an incremental regression. I had a simple one-line shell script which ran cargo twice, checking for specific behavior. I don't see a way to do that with this tool.

Adding the rustc-dev component

Hi,
First, this is an awesome tool that I use frequently :)
Second, I want to bisect something that uses rustc_ast, so for that I need also rustc-dev and currently it's not possible AFAIU.

Thanks!

Add support for link failure regressions

From a conversation that began in #53 (comment)

It would be helpful to be able to define link failure errors as the regression definition. This could be supported through a new hard coded field as of the #53 changes, or supported with a new command line option that takes a substring for the stderr message search.

More by-commit builds are available than what bisect-rustc wants to try

I had an old range of commits to bisect through, and bisect-rustc would tell me that they were all older than 90 days, but apparently, rustup-toolchain-install-master can find builds for them...

Include commit SHA in GitHub API commit query reporting

I ran bisect-rustc with the new GitHub API support (#63) for a rust ICE and landed on a nightly that is outside of the 167 day range for CI / commit bisection support. The report from the tool ended with the commit dump:

commit[0] 2019-08-19UTC: Auto merge of #63579 - alexcrichton:new-lockfile, r=Mark-Simulacrum
commit[1] 2019-08-19UTC: Auto merge of #63715 - Centril:rollup-dga8qtp, r=Centril
commit[2] 2019-08-20UTC: Auto merge of #62727 - SimonSapin:plugins-tls-dylib, r=petrochenkov
commit[3] 2019-08-20UTC: Auto merge of #63497 - eddyb:miri-subst, r=oli-obk
commit[4] 2019-08-20UTC: Auto merge of #63709 - matklad:decomposed-tokens, r=petrochenkov
commit[5] 2019-08-20UTC: Auto merge of #63587 - flip1995:clippyup, r=flip1995
commit[6] 2019-08-20UTC: Auto merge of #63744 - Centril:rollup-g4l3ra9, r=Centril
commit[7] 2019-08-20UTC: Auto merge of #63752 - Centril:rollup-nlxwety, r=Centril

It would be helpful to include the short git commit SHA's in this report so that "manual" bisection can be performed over the commits.

Trigger bisect from GitHub comments

It seems like it could be possible (given the resources) to automatically bisect by mentioning a bot on an issue / PR. For example, in these recent issues: rust-lang/rust#49706 and rust-lang/rust#49438 the next steps are "run cargo-bisect-rustc. It'd be nice to do this without any intervention other than a comment.

Add an interactive mode

In some cases, like performance regression, it's hard to write reliable automated tests to drive the bisection. It would be great to have a git-bisect like interactive mode allowing to run commands manually and then tag whether the tested version was good or bad.

Expected author Brian Anderson to be bors

bisecting ci builds
starting at a01b0bf0fbd870bec1747318bc081ac4a0606fb8, ending at 2442823ef572a65092fbc46f6975633f983b50b6
fetching commits from a01b0bf0fbd870bec1747318bc081ac4a0606fb8 to 2442823ef572a65092fbc46f6975633f983b50b6
opening existing repository at "rust.git"
refreshing repository
looking up first commit
looking up second commit
checking that commits are by bors and thus have ci artifacts...
finding bors merge commits
Expected author Brian Anderson to be bors for beb9a0dfc52ebda4f8db4e5d439e08e4f3a43a39

Add support for stack overflow error regressions

From a conversation that began in #53 (comment)

It would be helpful to support stack overflow errors as the regression definition. This can be hard coded with the current --regress= definition approach as of #53 , or supported through a new command line option that takes a substring for the stderr message search.

leverage existing rustup nightlies

We could avoid network traffic (which to me seems like the big bottleneck, at least when one isn't using the --preserve flag to cargo-bisect-rustc) by looking at what nightlies the user has already installed via rustup, and first testing them before exploring versions that we would have to download from the CI service.

Using the Github API instead of a local git repository

If you want to use this tool you either specify a local git repository at compile time or it will always clone a bare repository on every cargo-bisect-rustc run.

This is somewhat inconvenient and using the Github API is something one could do instead.

What are your thoughts about it? I'd like to implement it, maybe as a flag (--no-local-git-repo-is-available-so-use-github-instead-plz)

Downloaded toolchains do not support components

Scope

I'm trying to use cargo-bisect-rustc to find when a size regression for the msp430 target was introduced. Right now, msp430 requires xargo to build, which is essentially a small wrapper over cargo that compiles libcore on-the-fly while msp430's libcore isn't built as part of CI.

xargo itself requires that the rustup component rust-src is available. However, when I attempt to run cargo-bisect-rustc against a sample repo with the regression, the script I provide always fails with error: toolchain 'bisector-nightly-2019-03-27-x86_64-unknown-linux-gnu' does not support components.

The bisector- prefix appears to be deliberate. However, I can't obtain the rust-src corresponding to each nightly thanks to the prefix. Therefore, I can't use this tool to bisect and look for when the size regression was introduced.

What options do I have?

Output

`test.sh`

#!/bin/sh
NOBM_FILE=`mktemp`
BM_FILE=`mktemp`

rustup component add rust-src

xargo build --manifest-path=take-api/Cargo.toml --release --target=msp430-none-elf --example min --features bare_metal
msp430-elf-size -A target/msp430-none-elf/release/examples/min > $BM_FILE

xargo build --manifest-path=take-api/Cargo.toml --release --target=msp430-none-elf --example min
msp430-elf-size -A target/msp430-none-elf/release/examples/min > $NOBM_FILE

diff -u $NOBM_FILE $BM_FILE

rm $NOBM_FILE $BM_FILE

william@xubuntu-dtrain:~/Projects/msp430-size$ cargo-bisect-rustc --script=./test.sh --preserve-target --preserve --start=2019-03-27 --end=2019-09-04 --prompt
checking nightly-2019-03-27
error: toolchain 'bisector-nightly-2019-03-27-x86_64-unknown-linux-gnu' does not support components
error: caused by: invalid toolchain name: 'bisector-nightly-2019-03-27-x86_64-unknown-linux-gnu'
error: `rust-src` component not found. Run `rustup component add rust-src`.
note: run with `RUST_BACKTRACE=1` for a backtrace
error: `rust-src` component not found. Run `rustup component add rust-src`.
note: run with `RUST_BACKTRACE=1` for a backtrace


nightly-2019-03-27 finished with exit code Some(0).
please select an action to take:
> mark regressed
  mark baseline
  retry

feature request: Invert status

Add ability to look for any change in success status. i.e. not only went from good to bad, but also from bad to good.

Support short SHAs

I tried using --start 6a1c0637c --end 866a71325 but that ran into an assertion failure:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"6a1c0637ce44aeea6c60527f4c0e7fb33f2bcd0d"`,
 right: `"6a1c0637c"`', src/main.rs:70:5

It would be nice if short SHAs were supported, then one could use the output of rustc --version to determine which commits match a nightly.

Add example invocation to --help

Just seeing an example like

cargo bisect-rustc --start 6a1c0637ce44aeea6c60527f4c0e7fb33f2bcd0d --end 866a713258915e6cbb212d135f751a6a8c9e1c0a --test-dir ../rustc-perf/collector/benchmarks/ctfe-stress/ --prompt -- build

would have been very helpful. However, I looked over the structopt docs and could not even find a way to add that. Am I missing something?

Builds fail on Windows GH Actions runner

On windows-latest I am seeing the following build error:

error[E0432]: unresolved import `winapi_util::console::Console`
##[error]   --> C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\console-0.11.2\src\term.rs:439:17
    |
439 |             use winapi_util::console::Console;
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `Console` in `console`

error[E0432]: unresolved imports `winapi_util::console::Color`, `winapi_util::console::Console`, `winapi_util::console::Intense`
##[error]  --> C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\console-0.11.2\src\windows_term.rs:36:28
   |
36 | use winapi_util::console::{Color, Console, Intense};
   |                            ^^^^^  ^^^^^^^  ^^^^^^^ no `Intense` in `console`
   |                            |      |
   |                            |      no `Console` in `console`
   |                            no `Color` in `console`

error: aborting due to 2 previous errors
##[error]aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0432`.
error: could not compile `console`.
##[error]could not compile `console`.
To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
##[warning]error: build failed
##[error]The process 'C:\Rust\.cargo\bin\cargo.exe' failed with exit code 101

Cannot find regression due to suppressed merge commits

When bisecting rust-lang/rust#77638, bisect-rustc said
that the regression is in nightly-2020-10-06, commit between 2020-10-05 and 2020-10-06.
However, and it only searchs from rust-lang/rust@beb5ae4 to rust-lang/rust@a1dfd24, which contains 8 commits, and none causing the regression:

finding bors merge commits
found 8 bors merge commits in the specified range
  commit[0] 2020-10-04UTC: Auto merge of #77023 - HeroicKatora:len-missed-optimization, r=Mark-Simulacrum
  commit[1] 2020-10-05UTC: Auto merge of #77466 - Aaron1011:reland-drop-tree, r=matthewjasper
  commit[2] 2020-10-05UTC: Auto merge of #77557 - Dylan-DPC:rollup-aib9ptp, r=Dylan-DPC
  commit[3] 2020-10-05UTC: Auto merge of #77552 - ecstatic-morse:body-def-id, r=lcnr
  commit[4] 2020-10-05UTC: Auto merge of #77549 - tmiasko:simplify-branch-same-fix, r=oli-obk
  commit[5] 2020-10-05UTC: Auto merge of #77543 - Mark-Simulacrum:rsp-quoting, r=eddyb
  commit[6] 2020-10-05UTC: Auto merge of #77171 - VFLashM:better_sso_structures, r=oli-obk
  commit[7] 2020-10-05UTC: Auto merge of #77080 - richkadel:llvm-coverage-counters-2, r=tmandry

Indeed, using git log directly show the same result:

$ git lg --author bors --since 2020-10-05 --until 2020-10-06 --date iso
* a1dfd2490a6 - Auto merge of #77080 - richkadel:llvm-coverage-counters-2, r=tmandry (33 hours ago)<bors>
* ea7e131435a - Auto merge of #77171 - VFLashM:better_sso_structures, r=oli-obk (35 hours ago)<bors>
* f317a93d4d3 - Auto merge of #77543 - Mark-Simulacrum:rsp-quoting, r=eddyb (2 days ago)<bors>
* d890e64dff3 - Auto merge of #77549 - tmiasko:simplify-branch-same-fix, r=oli-obk (2 days ago)<bors>
* 62bfcfd8a3b - Auto merge of #77552 - ecstatic-morse:body-def-id, r=lcnr (2 days ago)<bors>

But we aware that any merge commits merged before 00:00 UTC (daily time of rust-release)
of the 2020-10-07 will be include in nightly-2020-10-06.
Which mean that the correct command should be:

$ git lg --author bors --since '2020-10-06 00:00' --until '2020-10-07 00:00' --date=iso
* 59dafb876e1 - Auto merge of #77630 - Dylan-DPC:rollup-kfwl55z, r=Dylan-DPC (6 hours ago)<bors>
* 98edd1fbf8a - Auto merge of #77386 - joshtriplett:static-glibc, r=petrochenkov (8 hours ago)<bors>
* 9fdaeb393a1 - Auto merge of #76356 - caass:hooks, r=jyn514 (14 hours ago)<bors>
* 08e2d461661 - Auto merge of #73905 - matthewjasper:projection-bounds-2, r=nikomatsakis (16 hours ago)<bors>
* 5849a7eca90 - Auto merge of #77594 - timvermeulen:chain_advance_by, r=scottmcm (18 hours ago)<bors>
* 5ded3945532 - Auto merge of #77606 - JohnTitor:rollup-7rgahdt, r=JohnTitor (21 hours ago)<bors>

cc @Mark-Simulacrum