Auto merge of #127538 - Oneirical:the-sacred-tests, r=jieyouxu

Migrate `issue-83112-incr-test-moved-file`, `type-mismatch-same-crate-name` and `issue-109934-lto-debuginfo` `run-make` tests to rmake or ui

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

I have noticed that the new UI test `debuginfo-lto-alloc` is outputting artifacts that aren't getting cleaned up because of its `-C incremental`. That might be the justification needed to keep it as a run-make test?

Try it on:

// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc

src/tools/tidy/src/allowed_run_make_makefiles.txt

@@ -46,7 +46,6 @@ run-make/incr-add-rust-src-component/Makefile
 run-make/incr-foreign-head-span/Makefile
 run-make/interdependent-c-libraries/Makefile
 run-make/issue-107094/Makefile
-run-make/issue-109934-lto-debuginfo/Makefile
 run-make/issue-14698/Makefile
 run-make/issue-15460/Makefile
 run-make/issue-18943/Makefile
@@ -60,7 +59,6 @@ run-make/issue-36710/Makefile
 run-make/issue-47551/Makefile
 run-make/issue-69368/Makefile
 run-make/issue-83045/Makefile
-run-make/issue-83112-incr-test-moved-file/Makefile
 run-make/issue-84395-lto-embed-bitcode/Makefile
 run-make/issue-85019-moved-src-dir/Makefile
 run-make/issue-85401-static-mir/Makefile
@@ -138,6 +136,5 @@ run-make/test-benches/Makefile
 run-make/thumb-none-cortex-m/Makefile
 run-make/thumb-none-qemu/Makefile
 run-make/translation/Makefile
-run-make/type-mismatch-same-crate-name/Makefile
 run-make/unstable-flag-required/Makefile
 run-make/x86_64-fortanix-unknown-sgx-lvi/Makefile

tests/run-make/incr-test-moved-file/rmake.rs

@@ -0,0 +1,27 @@
+// The generated test harness code contains spans with a dummy location,
+// but a non-dummy SyntaxContext. Previously, the incremental cache was encoding
+// these spans as a full span (with a source file index), instead of skipping
+// the encoding of the location information. If the file gest moved, the hash
+// of the span will be unchanged (since it has a dummy location), so the incr
+// cache would end up try to load a non-existent file using the previously
+// enccoded source file id.
+// This test reproduces the steps that used to trigger this bug, and checks
+// for successful compilation.
+// See https://github.com/rust-lang/rust/issues/83112
+
+//@ ignore-none
+// Reason: no-std is not supported
+//@ ignore-nvptx64-nvidia-cuda
+// FIXME: can't find crate for 'std'
+
+use run_make_support::{fs_wrapper, rust_lib_name, rustc};
+
+fn main() {
+    fs_wrapper::create_dir("incr");
+    fs_wrapper::create_dir("src");
+    fs_wrapper::create_dir("src/mydir");
+    fs_wrapper::copy("main.rs", "src/main.rs");
+    rustc().input("src/main.rs").incremental("incr").arg("--test").run();
+    fs_wrapper::rename("src/main.rs", "src/mydir/main.rs");
+    rustc().input("src/mydir/main.rs").incremental("incr").arg("--test").run();
+}

tests/run-make/issue-109934-lto-debuginfo/Makefile

@@ -1,12 +0,0 @@
-# ignore-cross-compile
-include ../tools.mk
-
-# With the upgrade to LLVM 16, this was getting:
-#
-#   error: Cannot represent a difference across sections
-#
-# The error stemmed from DI function definitions under type scopes, fixed by
-# only declaring in type scope and defining the subprogram elsewhere.
-
-all:
-	$(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat

tests/run-make/issue-109934-lto-debuginfo/lib.rs

@@ -1,9 +0,0 @@
-extern crate alloc;
-
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn something_alloc() {
-        assert_eq!(Vec::<u32>::new(), Vec::<u32>::new());
-    }
-}

tests/run-make/issue-83112-incr-test-moved-file/Makefile

@@ -1,25 +0,0 @@
-include ../tools.mk
-
-# ignore-none no-std is not supported
-# ignore-nvptx64-nvidia-cuda FIXME: can't find crate for 'std'
-
-# Regression test for issue #83112
-# The generated test harness code contains spans with a dummy location,
-# but a non-dummy SyntaxContext. Previously, the incremental cache was encoding
-# these spans as a full span (with a source file index), instead of skipping
-# the encoding of the location information. If the file gest moved, the hash
-# of the span will be unchanged (since it has a dummy location), so the incr
-# cache would end up try to load a non-existent file using the previously
-# enccoded source file id.
-
-SRC=$(TMPDIR)/src
-INCR=$(TMPDIR)/incr
-
-all:
-	mkdir $(SRC)
-	mkdir $(SRC)/mydir
-	mkdir $(INCR)
-	cp main.rs $(SRC)/main.rs
-	$(RUSTC) --test -C incremental=$(INCR) $(SRC)/main.rs --target $(TARGET)
-	mv $(SRC)/main.rs $(SRC)/mydir/main.rs
-	$(RUSTC) --test -C incremental=$(INCR) $(SRC)/mydir/main.rs --target $(TARGET)

tests/run-make/type-mismatch-same-crate-name/Makefile

@@ -1,19 +0,0 @@
-include ../tools.mk
-
-all:
-	# compile two different versions of crateA
-	$(RUSTC) --crate-type=rlib crateA.rs -C metadata=-1 -C extra-filename=-1
-	$(RUSTC) --crate-type=rlib crateA.rs -C metadata=-2 -C extra-filename=-2
-	# make crateB depend on version 1 of crateA
-	$(RUSTC) --crate-type=rlib crateB.rs --extern crateA=$(TMPDIR)/libcrateA-1.rlib
-	# make crateC depend on version 2 of crateA
-	$(RUSTC) crateC.rs --extern crateA=$(TMPDIR)/libcrateA-2.rlib 2>&1 | \
-		tr -d '\r\n' | $(CGREP) -e \
-	"mismatched types.*\
-	crateB::try_foo\(foo2\);.*\
-	expected \`crateA::foo::Foo\`, found \`Foo\`.*\
-	different versions of crate \`crateA\`.*\
-	mismatched types.*\
-	crateB::try_bar\(bar2\);.*\
-	expected trait \`crateA::bar::Bar\`, found trait \`Bar\`.*\
-	different versions of crate \`crateA\`"

tests/run-make/type-mismatch-same-crate-name/rmake.rs

@@ -0,0 +1,29 @@
+// When a compilation failure deals with seemingly identical types, some helpful
+// errors should be printed.
+// The main use case of this error is when there are two crates
+// (generally different versions of the same crate) with the same name
+// causing a type mismatch. In this test, one of the crates
+// is only introduced as an indirect dependency and the type is accessed via a reexport.
+// See https://github.com/rust-lang/rust/pull/42826
+
+use run_make_support::{rust_lib_name, rustc};
+
+fn main() {
+    rustc().crate_type("rlib").input("crateA.rs").metadata("-1").extra_filename("-1").run();
+    rustc().crate_type("rlib").input("crateA.rs").metadata("-2").extra_filename("-2").run();
+    rustc()
+        .crate_type("rlib")
+        .input("crateB.rs")
+        .extern_("crateA", rust_lib_name("crateA-1"))
+        .run();
+    rustc()
+        .input("crateC.rs")
+        .extern_("crateA", rust_lib_name("crateA-2"))
+        .run_fail()
+        .assert_stderr_contains("mismatched types")
+        .assert_stderr_contains("crateB::try_foo(foo2);")
+        .assert_stderr_contains("different versions of crate `crateA`")
+        .assert_stderr_contains("crateB::try_bar(bar2);")
+        .assert_stderr_contains("expected trait `crateA::bar::Bar`, found trait `Bar`")
+        .assert_stderr_contains("different versions of crate `crateA`");
+}

tests/ui/lto/debuginfo-lto-alloc.rs

@@ -0,0 +1,22 @@
+// With the upgrade to LLVM 16, the following error appeared when using
+// link-time-optimization (LTO) alloc and debug compilation mode simultaneously:
+//
+//   error: Cannot represent a difference across sections
+//
+// The error stemmed from DI function definitions under type scopes, fixed by
+// only declaring in type scope and defining the subprogram elsewhere.
+// This test reproduces the circumstances that caused the error to appear, and checks
+// that compilation is successful.
+
+//@ check-pass
+//@ compile-flags: --test -C debuginfo=2 -C lto=fat -C incremental=inc-fat
+
+extern crate alloc;
+
+#[cfg(test)]
+mod tests {
+    #[test]
+    fn something_alloc() {
+        assert_eq!(Vec::<u32>::new(), Vec::<u32>::new());
+    }
+}