a8cda30f32
Don't accidentally detect the commit hash as an `fadd` instruction I've seen some reports of `tests/codegen/target-feature-inline-closure.rs` spuriously failing because it thinks the hash in the rustc version number contains an `fadd` instruction. https://github.com/rust-lang/rust/pull/116085#issuecomment-1751174916 https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Is.20.60tests.2Fcodegen.2Ftarget-feature-inline-closure.2Ers.60.20flakey https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Strange.20.5Cn.20in.20output.20of.20assert.20.23108341/near/395811335 This PR tries to make that not happen by adding a `CHECK-LABEL` directive that will match the line with the rustc version string, preventing the previous `CHECK-NOT` from seeing it.
The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.
One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:
// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb
After specifying those variations, you can write different expected, or
explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:,
like so:
// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT: emitted-only-for-bbb
// bbb-NOT: emitted-only-for-aaa
// bbb-SAME: emitted-only-for-bbb