cleaned up some tests

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

@@ -1,19 +1,20 @@
+//! 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
 
-#![allow(non_upper_case_globals)]
-#![allow(dead_code)]
-/*!
- * On x86_64-linux-gnu and possibly other platforms, structs get 8-byte "preferred" alignment,
- * but their "ABI" alignment (i.e., what actually matters for data layout) is the largest alignment
- * of any field. (Also, `u64` has 8-byte ABI alignment; this is not always true).
- *
- * On such platforms, if monomorphize uses the "preferred" alignment, then it will unify
- * `A` and `B`, even though `S<A>` and `S<B>` have the field `t` at different offsets,
- * and apply the wrong instance of the method `unwrap`.
- */
-
 #[derive(Copy, Clone)]
-struct S<T> { i:u8, t:T }
+struct S<T> {
+    #[allow(dead_code)]
+    i: u8,
+    t: T,
+}
 
 impl<T> S<T> {
     fn unwrap(self) -> T {
@@ -22,14 +23,15 @@ fn unwrap(self) -> T {
 }
 
 #[derive(Copy, Clone, PartialEq, Debug)]
-struct A((u32, u32));
+struct A((u32, u32)); // Different ABI alignment than B
 
 #[derive(Copy, Clone, PartialEq, Debug)]
-struct B(u64);
+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));
+    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

@@ -1,12 +1,18 @@
-// A previously outdated version of LLVM caused compilation failures on Windows
-// specifically with optimization level `z`. After the update to a more recent LLVM
-// version, this test checks that compilation and execution both succeed.
-// See https://github.com/rust-lang/rust/issues/45034
+//! 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 occurs on Windows
+// Reason: the observed bug only occurred on Windows MSVC targets
 //@ run-pass
 //@ compile-flags: -C opt-level=z
 
@@ -20,8 +26,8 @@ fn foo(x: i32, y: i32) -> 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, see issue #45034
+    // 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));
 }

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

@@ -1,8 +1,18 @@
-//@ run-pass
-//@ aux-build:msvc-data-only-lib.rs
+//! 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>.
 
-extern crate msvc_data_only_lib;
+//@ run-pass
+//@ aux-build:msvc-static-data-import-lib.rs
+
+extern crate msvc_static_data_import_lib;
 
 fn main() {
-    println!("The answer is {} !", msvc_data_only_lib::FOO);
+    println!("The answer is {}!", msvc_static_data_import_lib::FOO);
 }

tests/ui/parser/multiline-comments-basic.rs

@@ -1,6 +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 oldcomment.
+ * This is a multi-line comment.
  */
-pub fn main() { }
+pub fn main() {}

tests/ui/parser/unicode-multibyte-chars-no-ice.rs

@@ -1,7 +1,9 @@
-//@ run-pass
-//
+//! Test that multibyte Unicode characters don't crash the compiler.
+//!
+//! Regression test for <https://github.com/rust-lang/rust/issues/4780>.
+
+//@ run-pass
 
-// Test that multibyte characters don't crash the compiler
 pub fn main() {
     println!("마이너스 사인이 없으면");
 }