Rollup merge of rust-lang#143195 - Kivooeo:tf17, r=tgross35

`tests/ui`: A New Order [17/N]

> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.

Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang#133895.

r? `@tgross35`

Author: dianqk

tests/ui/codegen/mono-respects-abi-alignment.rs

@@ -0,0 +1,37 @@
+//! Test that monomorphization correctly distinguishes types with different ABI alignment.
+//!
+//! On x86_64-linux-gnu and similar platforms, structs get 8-byte "preferred"
+//! alignment, but their "ABI" alignment (what actually matters for data layout)
+//! is the largest alignment of any field. If monomorphization incorrectly uses
+//! "preferred" alignment instead of "ABI" alignment, it might unify types `A`
+//! and `B` even though `S<A>` and `S<B>` have field `t` at different offsets,
+//! leading to incorrect method dispatch for `unwrap()`.
+
+//@ run-pass
+
+#[derive(Copy, Clone)]
+struct S<T> {
+    #[allow(dead_code)]
+    i: u8,
+    t: T,
+}
+
+impl<T> S<T> {
+    fn unwrap(self) -> T {
+        self.t
+    }
+}
+
+#[derive(Copy, Clone, PartialEq, Debug)]
+struct A((u32, u32)); // Different ABI alignment than B
+
+#[derive(Copy, Clone, PartialEq, Debug)]
+struct B(u64); // Different ABI alignment than A
+
+pub fn main() {
+    static CA: S<A> = S { i: 0, t: A((13, 104)) };
+    static CB: S<B> = S { i: 0, t: B(31337) };
+
+    assert_eq!(CA.unwrap(), A((13, 104)));
+    assert_eq!(CB.unwrap(), B(31337));
+}

tests/ui/codegen/msvc-opt-level-z-no-corruption.rs

@@ -0,0 +1,37 @@
+//! Test that opt-level=z produces correct code on Windows MSVC targets.
+//!
+//! A previously outdated version of LLVM caused compilation failures and
+//! generated invalid code on Windows specifically with optimization level `z`.
+//! The bug manifested as corrupted base pointers due to incorrect register
+//! usage in the generated assembly (e.g., `popl %esi` corrupting local variables).
+//! After updating to a more recent LLVM version, this test ensures that
+//! compilation and execution both succeed with opt-level=z.
+//!
+//! Regression test for <https://github.com/rust-lang/rust/issues/45034>.
+
+//@ ignore-cross-compile
+// Reason: the compiled binary is executed
+//@ only-windows
+// Reason: the observed bug only occurred on Windows MSVC targets
+//@ run-pass
+//@ compile-flags: -C opt-level=z
+
+#![feature(test)]
+extern crate test;
+
+fn foo(x: i32, y: i32) -> i64 {
+    (x + y) as i64
+}
+
+#[inline(never)]
+fn bar() {
+    let _f = Box::new(0);
+    // This call used to trigger an LLVM bug in opt-level=z where the base
+    // pointer gets corrupted due to incorrect register allocation
+    let y: fn(i32, i32) -> i64 = test::black_box(foo);
+    test::black_box(y(1, 2));
+}
+
+fn main() {
+    bar();
+}

tests/ui/auxiliary/msvc-data-only-lib.rs renamed to tests/ui/linkage-attr/auxiliary/msvc-static-data-import-lib.rs

@@ -0,0 +1,18 @@
+//! Test that static data from external crates can be imported on MSVC targets.
+//!
+//! On Windows MSVC targets, static data from external rlibs must be imported
+//! through `__imp_<symbol>` stubs to ensure proper linking. Without this,
+//! the linker would fail with "unresolved external symbol" errors when trying
+//! to reference static data from another crate.
+//!
+//! Regression test for <https://github.com/rust-lang/rust/issues/26591>.
+//! Fixed in <https://github.com/rust-lang/rust/pull/28646>.
+
+//@ run-pass
+//@ aux-build:msvc-static-data-import-lib.rs
+
+extern crate msvc_static_data_import_lib;
+
+fn main() {
+    println!("The answer is {}!", msvc_static_data_import_lib::FOO);
+}

tests/ui/linkage-attr/msvc-static-data-import.rs

@@ -0,0 +1,10 @@
+//! Test that basic multiline comments are parsed correctly.
+//!
+//! Feature implementation test for <https://github.com/rust-lang/rust/issues/66>.
+
+//@ run-pass
+
+/*
+ * This is a multi-line comment.
+ */
+pub fn main() {}