Add more exceptions to the list

[est31]

I would also love #667 to be merged, but this probably has to happen after this PR as this PR fixes clippy.

[est31]

r? @Mark-Simulacrum

[rustbot]

Error: This repository is not enabled to use triagebot.
Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[est31]

Oh this needs to wait until after rust-lang/rust#103654 has been merged and put into nightly (edit: or I can just address the lint anyways).

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 02280c6 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 02280c6 with merge 53db254...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 53db254 to master...

[RalfJung]

FWIW these are probably almost all caused by #663. Basically every crate that links libc or a proc macro shows these symptoms. Excluding some of them is fairly pointless unless we aim at eventually excluding all of them... if we have 10k crates that fail with a rate of 0.1%, excluding 10 of them makes no difference whatsoever.

[est31]

I agree that it's pointless to add crates that "won" the 0.1% lottery. And I did indeed encounter a lot of instances of #663, but the exceptions this PR is adding are different. Unlike #663, these failures were consistent: the same crates showed up in an earlier crater report too of an unrelated PR, see the commit msg of 573d5df .

I'm not 100% sure how these errors occured but they seem to be consistent. For binja-rs, I have somewhat of an idea: OUT_DIR does not change between nightly versions or different rustc builds (not sure why but local testing confirms that), and both the new and old build.rs are putting a symlink into OUT_DIR. Why the check "does the symlink already exist" doesn't work I'm not sure, maybe due to the race condition that the Path::exists docs warn you about? IDK. For the snippet of the relevant code, see the "file already exists error" section of my triage comment, but note that I was wrong with the path being erroneously calculated, upon second inspection it was calculated correctly. The glsl validation issue, which occurs in a proc macro, is less clear to me how it comes to be... but it does also fail consistently.

[est31]

FTR, except for vulkano_tri1 and vulkano_examples, I could also find the things this PR is adding in both crater runs of your PR: rust-lang/rust#102513 (comment) and rust-lang/rust#102513 (comment) . I've checked the vulkano repos, they seem to run into OOM issues (listed as build-fail), probably due to an artifact of the build environment, so likely that's why the bug is not surfacing.

Note that I sided on the side of caution when making this PR, and thus this PR only added a tiny subset of the spurious failures to the blacklist.

[RalfJung]

Ah, fair. :) The symlimk part does not make sense to me though, doesn't crater run baseline and try build in completely separate containers?

[est31]

doesn't crater run baseline and try build in completely separate containers?

If you compare the before and after (i open them in two tabs, scroll to the same position, and then switch back and forth using ctrl + pg up / down), you see that the it downloads some dependencies both from github as well as from crates.io in one job.

Also if you check the invoked commands, it seems to set CARGO_TARGET_DIR=/opt/rustwide/target in the docker container, and also call the -v flag to mount a directory from the host into the container:

/var/lib/crater-agent-workspace/builds/worker-7/target:/opt/rustwide/target

Maybe that mapping also explains why the check is going wrong: the symlink is seen as non-existent by the check because it doesn't resolve in the host's file system.