Auto merge of #127538 - Oneirical:the-sacred-tests, r=<try>

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

Author: bors

src/tools/tidy/src/allowed_run_make_makefiles.txt

@@ -48,7 +48,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
@@ -62,7 +61,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
@@ -143,6 +141,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/issue-83112-incr-test-moved-file/main.rs renamed to tests/run-make/incr-test-moved-file/main.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/incr-test-moved-file/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/run-make/issue-109934-lto-debuginfo/Makefile

@@ -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());
+    }
+}