rust-lang / cargo-bisect-rustc Goto Github PK
View Code? Open in Web Editor NEWBisects rustc, either nightlies or CI artifacts
Home Page: https://rust-lang.github.io/cargo-bisect-rustc/
License: Apache License 2.0
Bisects rustc, either nightlies or CI artifacts
Home Page: https://rust-lang.github.io/cargo-bisect-rustc/
License: Apache License 2.0
Hi, I'm using macOS Catalina 10.15.1 and I get an error when doing cargo install cargo-bisect-rustc
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
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)
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?
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
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!
To bisect hangs.
$ 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?
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
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.
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)".
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).
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.
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.
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
.
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.
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)
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...
Outputs a simple "No such file or directory (os error 2)".
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.
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?
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.
As titled. Running cargo bisect-rustc
without any arguments should find regression using the current project.
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.
--by-commit fails, as of writing, with:
expected to start with 927c55d86b0be44337f37cf5b0a76fb8ba86e06c, but started with 565907fefb2a69c279b59bffa84c6d30129cafe9
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.
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
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.
# 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
Is it possible it could figure out which PR in a roll-up was responsible?
That really would be the ICEing on the cake.
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?
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.
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
.
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
)
Line 11 in 843b96e
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 ?
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.
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.
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>
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
(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.
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
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.
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
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
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.
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
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.
--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
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?
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
When hitting Ctrl-C when bisect-rustc is working, files may be left in a temporary location. They should be automatically cleaned up.
On my system openssl < 1.0.1 is not available and thus the build fails due to sfackler/rust-openssl#987
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.