`./x.py test src/test/codegen` fails

[RalfJung]

Codegen tests currently fail in stage 1:

---- [codegen] src/test/codegen/mem-replace-direct-memcpy.rs stdout ----

error: verification with 'FileCheck' failed
status: exit status: 1
command: "/home/r/src/rust/rustc.3/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/home/r/src/rust/rustc.3/build/x86_64-unknown-linux-gnu/test/codegen/mem-replace-direct-memcpy/mem-replace-direct-memcpy.ll" "/home/r/src/rust/rustc.3/src/test/codegen/mem-replace-direct-memcpy.rs" "--allow-unused-prefixes" "--check-prefixes" "CHECK,NONMSVC"
stdout: none
--- stderr -------------------------------
/home/r/src/rust/rustc.3/src/test/codegen/mem-replace-direct-memcpy.rs:20:11: error: CHECK: expected string not found in input
// CHECK: call void @llvm.memcpy.{{.+}}({{i8\*|ptr}} align 1 %{{.*}}, {{i8\*|ptr}} align 1 %dest, i{{.*}} 1, i1 false)
          ^
/home/r/src/rust/rustc.3/build/x86_64-unknown-linux-gnu/test/codegen/mem-replace-direct-memcpy/mem-replace-direct-memcpy.ll:52:21: note: scanning from here
; core::mem::replace
                    ^
/home/r/src/rust/rustc.3/build/x86_64-unknown-linux-gnu/test/codegen/mem-replace-direct-memcpy/mem-replace-direct-memcpy.ll:138:2: note: possible intended match here
 call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %_4, i8* align 1 %src, i64 1, i1 false)
 ^

I think this started with #91743.

[eddyb]

This is because MIR inlining disables itself w/ incremental and you likely have incremental enabled locally.
Previous discussion can be found on Zulip.

My opinion is that we should just not check for incremental at all and just let it run.

[memark]

Just cloned the repo to maybe try and start contributing, immediately running into this failed test. Having read through the Zulip thread, it's still not clear to me what I need to do? Does this fail for everyone building/testing a fresh clone?

[jyn514]

I can't reproduce this locally on x86_64-unknown-linux-gnu, x test tests/codegen/mem-replace-direct-memcpy.rs passes. Is this still causing issues?

[RalfJung]

We had a bootstrap bump since I reported this, so this particular staging issue was resolved. But unless we run codegen tests in stage 1 on CI now, there is also nothing preventing this problem from reappearing in the future.

[jyn514]

@RalfJung we run them in CI since #99529 :)