Migrate lto-empty, invalid-so and issue-20626 run-make tests to rmake.rs

src/tools/tidy/src/allowed_run_make_makefiles.txt

@@ -55,13 +55,11 @@ run-make/incr-foreign-head-span/Makefile
 run-make/interdependent-c-libraries/Makefile
 run-make/intrinsic-unreachable/Makefile
 run-make/invalid-library/Makefile
-run-make/invalid-so/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
-run-make/issue-20626/Makefile
 run-make/issue-22131/Makefile
 run-make/issue-25581/Makefile
 run-make/issue-26006/Makefile
@@ -97,7 +95,6 @@ run-make/long-linker-command-lines-cmd-exe/Makefile
 run-make/long-linker-command-lines/Makefile
 run-make/longjmp-across-rust/Makefile
 run-make/lto-dylib-dep/Makefile
-run-make/lto-empty/Makefile
 run-make/lto-linkage-used-attr/Makefile
 run-make/lto-no-link-whole-rlib/Makefile
 run-make/lto-smoke-c/Makefile

tests/run-make/invalid-so/rmake.rs

@@ -0,0 +1,17 @@
+// When a fake library was given to the compiler, it would
+// result in an obscure and unhelpful error message. This test
+// creates a false "foo" dylib, and checks that the standard error
+// explains that the file exists, but that its metadata is incorrect.
+// See https://github.com/rust-lang/rust/pull/88368
+
+use run_make_support::{dynamic_lib_name, fs_wrapper, rustc};
+
+fn main() {
+    fs_wrapper::create_file(dynamic_lib_name("foo"));
+    rustc()
+        .crate_type("lib")
+        .extern_("foo", dynamic_lib_name("foo"))
+        .input("bar.rs")
+        .run_fail()
+        .assert_stderr_contains("invalid metadata files for crate `foo`");
+}

tests/run-make/lto-empty/rmake.rs

@@ -0,0 +1,17 @@
+// Compiling Rust code twice in a row with "fat" link-time-optimizations used to cause
+// an internal compiler error (ICE). This was due to how the compiler would cache some modules
+// to make subsequent compilations faster, at least one of which was required for LTO to link
+// into. After this was patched in #63956, this test checks that the bug does not make
+// a resurgence.
+// See https://github.com/rust-lang/rust/issues/63349
+
+//@ ignore-cross-compile
+
+use run_make_support::rustc;
+
+fn main() {
+    rustc().input("lib.rs").arg("-Clto=fat").opt_level("3").incremental("inc-fat").run();
+    rustc().input("lib.rs").arg("-Clto=fat").opt_level("3").incremental("inc-fat").run();
+    rustc().input("lib.rs").arg("-Clto=thin").opt_level("3").incremental("inc-thin").run();
+    rustc().input("lib.rs").arg("-Clto=thin").opt_level("3").incremental("inc-thin").run();
+}

tests/run-make/raw-fn-pointer-opt-undefined-behavior/rmake.rs

@@ -0,0 +1,16 @@
+// Despite the absence of any unsafe Rust code, foo.rs in this test would,
+// because of the raw function pointer,
+// cause undefined behavior and fail to print the expected result, "4" -
+// only when activating optimizations (opt-level 2). This test checks
+// that this bug does not make a resurgence.
+// Note that the bug cannot be observed in an assert_eq!, only in the stdout.
+// See https://github.com/rust-lang/rust/issues/20626
+
+//@ ignore-cross-compile
+
+use run_make_support::{run, rustc};
+
+fn main() {
+    rustc().input("foo.rs").opt().run();
+    run("foo").assert_stdout_equals("4");
+}