reclassify prepare failure

[Skgland]

Currently prepare failure gets classified as Error unless the crate is determined to be broken in which case its classified as Broken. This PR reclassifies the former.

Most if not all of the perpare errors are spurious and would benefit from being included in the retry-regressed-list.txt so that they can be retried.

This should cause instances such as https://crater-reports.s3.amazonaws.com/beta-1.86-rustdoc-1/1.85.0/reg/ssstar-0.7.3/log.txt to be classified as prepare-fail instead of error which means the are included in the retry-regressed-list.txt and have a change at properly regressing in a retry.

This should help prevent regression in beta crater run being missed due to running out of disk space as was the case with the above example.

The first commit fixes existing clippy problems.

The second commit removes a no longer existing crate from the config.toml (broke config check)

The third commit cleans-up the compare match.
Basically a regression is spurious if the test toolchain result is spurious
and a fix is spurious if the base toolchain result is spurious.
This only changes the classification of BuildFail(non-spurious) -> TestFail(spurious) from SpuriousFixed to Fixed.
I think the new classification is correct and the old one was wrong.

The fourth commit adds a new Comparison and TestResult variant to properly classify the failure mode of preparation failing for a non-broken crate.
It also adds crates with this new Comparison variant to the retry-regressed-list.txt.

I expect this to significantly increase the size of the retry-regressed-list.txt.

Edit: Including PrepareFail in the retry-regressed-list.txt makes the file a bit misnamed, maybe it should be renamed to retry-list.txt the function for filtering the crates gen_retry_list already doesn't contain regressed in its name.

[Skgland]

Looking at the results from https://crater.rust-lang.org/ex/pr-140985
It mostly looks as I would expect.
Though the priority between Error, Broken and Prepare Fail looks like it could be better.

Currently it is Prepare Fail > Error > Broken but I think Broken > Prepare Fail > Error would be better.

I am a bit surprised by the remaining ~14k as the sample that I looked at looks to me like they should have been prepare fail instead, not sure what's going on there.

[Skgland]

Regarding the remaining ~14k Errors.

• the only place still emitting TestResult::Error is at

  crater/src/runner/worker.rs

  Line 149 in 2eb688f

  TestResult::Error

  • and there can't be an OverrideResult context added to the error e
• if I am not mistaken the only way to end up there is for

  crater/src/runner/test.rs

  Lines 254 to 257 in 2eb688f

  	detect_broken(build.run(|build| {
  	let local_packages = get_local_packages(build)?;
  	test_fn(ctx, build, &local_packages)
  	}))

  to return an Err(_)
• all possible test_fns only return Ok and never Err, so the source is either in get_local_packages or internal to build.run(..)
• based on the logs and kind of errors I am seeing it appears the source is mostly the build.run(..) call, more precisely the errors appear to occur in prepare.prepare() at https://github.com/rust-lang/rustwide/blob/8d0a3cbbf906691c9553965f207ef5f9cb913ca0/src/build.rs#L197

Ideally all failures of prepare would return a PrepareError so that detect_broken could properly sort the error reason into either PrepareFail or Broken, the former for transient errors and the later for permanent errors. Conservatively falling back to PrepareFail in case the nature of the error is unknown.