2024-08-31 did not have a nightly release. Using cargo bisect-rustc --start 1.82.0 gives this error.
$ cargo bisect-rustc --start=1.82.0
translating --start=1.82.0 to 2024-08-31
fetching https://static.rust-lang.org/dist/channel-rust-nightly-date.txt
nightly date: 10 B / 10 B [==================================================================================================================================] 100.00 % 341.41 KB/s determined the latest nightly is 2024-11-01
checking the start range to find a passing nightly
installing nightly-2024-08-31
uninstalling nightly-2024-08-31
*** unable to install nightly-2024-08-31. roll back one day and try again...
ERROR: could not find nightly-2024-08-31
Likewise, it errors with --end 1.82.0 on the "checking the end range to verify it does not pass" step.
$ cargo bisect-rustc --start=1.81.0 --end=1.82.0 --script=/bin/true
translating --start=1.81.0 to 2024-07-20
translating --end=1.82.0 to 2024-08-31
checking the start range to find a passing nightly
installing nightly-2024-07-20
rust-std-nightly-x86_64-unknown-linux-gnu: 27.13 MB / 27.13 MB [==============================================================================================] 100.00 % 16.94 MB/s testing...
RESULT: nightly-2024-07-20, ===> Script returned success
uninstalling nightly-2024-07-20
checking the end range to verify it does not pass
installing nightly-2024-08-31
uninstalling nightly-2024-08-31
ERROR: Could not find nightly-2024-08-31; url: https://static.rust-lang.org/dist/2024-08-31/rustc-nightly-x86_64-unknown-linux-gnu.tar.gz
It might make sense to automatically rollback the start date or rollforward the end date (a few times, up to the current day) if a given start boundary date did not have a nightly. Though this might be enough of an edge case to just leave it.
(I can make this a separate issue if it is important enough to deal with) Differently, if cargo bisect-rustc encounters 2024-08-31 in the middle of bisection, it will continue the bisection ignoring it, which is probably the best behavior, but could be more clearly stated in the output (it currently just says "installing " followed immediately by "uninstalling " with no indication of error).
$ cargo bisect-rustc --script=script.sh --start=2024-08-29 --end=2024-09-02
checking the start range to find a passing nightly
installing nightly-2024-08-29
rust-std-nightly-x86_64-unknown-linux-gnu: 26.27 MB / 26.27 MB [==============================================================================================] 100.00 % 11.39 MB/s testing...
RESULT: nightly-2024-08-29, ===> Script returned success
uninstalling nightly-2024-08-29
checking the end range to verify it does not pass
installing nightly-2024-09-02
rust-std-nightly-x86_64-unknown-linux-gnu: 25.98 MB / 25.98 MB [==============================================================================================] 100.00 % 12.01 MB/s testing...
RESULT: nightly-2024-09-02, ===> Script returned error
uninstalling nightly-2024-09-02
2 versions remaining to test after this (roughly 2 steps)
installing nightly-2024-08-31
uninstalling nightly-2024-08-31
2 versions remaining to test after this (roughly 2 steps)
installing nightly-2024-08-30
rustc-nightly-x86_64-unknown-linux-gnu: 51.24 MB / 72.04 MB [===================================================================>---------------------------] 71.13 % 10.21 MB/s 2s ^C
(I killed it here)
2024-08-31
did not have a nightly release. Usingcargo bisect-rustc --start 1.82.0
gives this error.Likewise, it errors with
--end 1.82.0
on the "checking the end range to verify it does not pass" step.It might make sense to automatically rollback the start date or rollforward the end date (a few times, up to the current day) if a given start boundary date did not have a nightly. Though this might be enough of an edge case to just leave it.
(I can make this a separate issue if it is important enough to deal with) Differently, if" followed immediately by "uninstalling " with no indication of error).
cargo bisect-rustc
encounters2024-08-31
in the middle of bisection, it will continue the bisection ignoring it, which is probably the best behavior, but could be more clearly stated in the output (it currently just says "installing