Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
pnkfelix opened this issue Feb 21, 2020 · 0 comments · Fixed by #55
Closed

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

pnkfelix opened this issue Feb 21, 2020 · 0 comments · Fixed by #55

Comments

@pnkfelix
Copy link
Member

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.
pnkfelix added a commit to pnkfelix/cargo-bisect-rustc that referenced this issue Feb 21, 2020
@pnkfelix
Fix code that was trying reuse an already installed nightly.
df4b571 
Before, we would just skip attempts to install a current nightly. (And then, we
would unconditionally fail the run as documented on issue rust-lang#54, regardless
whether of whether the regression was actually visible on that version, due to
it not being installed with the name "bisector-nightly-xxx" that we expect.)

This commit fixes that. It makes `install` call out to `rustup toolchain link`
to link the currently installed nightly up to the new new "bisector-nightly-xxx"
that we expect.

(I also refactored the code to construct `DownloadParams`, so that I could add a
comment in only one place noting an invariant that this commit is relying on.)
@pnkfelix pnkfelix mentioned this issue Feb 21, 2020
Merged
pnkfelix added a commit to pnkfelix/cargo-bisect-rustc that referenced this issue Feb 22, 2020
@pnkfelix
Fix code that was trying reuse an already installed nightly.
661b76d 
Before, we would just skip attempts to install a current nightly. (And then, we
would unconditionally fail the run as documented on issue rust-lang#54, regardless
whether of whether the regression was actually visible on that version, due to
it not being installed with the name "bisector-nightly-xxx" that we expect.)

This commit fixes that. It makes `install` call out to `rustup toolchain link`
to link the current rustc (as reported via `rustc --print sysroot`) up to the
new "bisector-nightly-xxx" that we expect.

(I also refactored the code to construct `DownloadParams`; that refactoring was
more relevant in an earlier version of the code that was linking in a different
(buggy) way.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Link to current nightly pnkfelix/cargo-bisect-rustc
1 participant
@pnkfelix