diff --git a/tests/ui/codegen/mono-respects-abi-alignment.rs b/tests/ui/codegen/mono-respects-abi-alignment.rs new file mode 100644 index 0000000000000..045d82b761fdc --- /dev/null +++ b/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` and `S` have field `t` at different offsets, +//! leading to incorrect method dispatch for `unwrap()`. + +//@ run-pass + +#[derive(Copy, Clone)] +struct S { + #[allow(dead_code)] + i: u8, + t: T, +} + +impl S { + 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 = S { i: 0, t: A((13, 104)) }; + static CB: S = S { i: 0, t: B(31337) }; + + assert_eq!(CA.unwrap(), A((13, 104))); + assert_eq!(CB.unwrap(), B(31337)); +} diff --git a/tests/ui/codegen/msvc-opt-level-z-no-corruption.rs b/tests/ui/codegen/msvc-opt-level-z-no-corruption.rs new file mode 100644 index 0000000000000..ba97acec82228 --- /dev/null +++ b/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 . + +//@ 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(); +} diff --git a/tests/ui/auxiliary/msvc-data-only-lib.rs b/tests/ui/linkage-attr/auxiliary/msvc-static-data-import-lib.rs similarity index 100% rename from tests/ui/auxiliary/msvc-data-only-lib.rs rename to tests/ui/linkage-attr/auxiliary/msvc-static-data-import-lib.rs diff --git a/tests/ui/linkage-attr/msvc-static-data-import.rs b/tests/ui/linkage-attr/msvc-static-data-import.rs new file mode 100644 index 0000000000000..e53eb404ef6ee --- /dev/null +++ b/tests/ui/linkage-attr/msvc-static-data-import.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_` 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 . +//! Fixed in . + +//@ 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); +} diff --git a/tests/ui/monomorphize-abi-alignment.rs b/tests/ui/monomorphize-abi-alignment.rs deleted file mode 100644 index 62df1aca357d7..0000000000000 --- a/tests/ui/monomorphize-abi-alignment.rs +++ /dev/null @@ -1,35 +0,0 @@ -//@ 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` and `S` have the field `t` at different offsets, - * and apply the wrong instance of the method `unwrap`. - */ - -#[derive(Copy, Clone)] -struct S { i:u8, t:T } - -impl S { - fn unwrap(self) -> T { - self.t - } -} - -#[derive(Copy, Clone, PartialEq, Debug)] -struct A((u32, u32)); - -#[derive(Copy, Clone, PartialEq, Debug)] -struct B(u64); - -pub fn main() { - static Ca: S = S { i: 0, t: A((13, 104)) }; - static Cb: S = S { i: 0, t: B(31337) }; - assert_eq!(Ca.unwrap(), A((13, 104))); - assert_eq!(Cb.unwrap(), B(31337)); -} diff --git a/tests/ui/msvc-data-only.rs b/tests/ui/msvc-data-only.rs deleted file mode 100644 index 15d799085fecc..0000000000000 --- a/tests/ui/msvc-data-only.rs +++ /dev/null @@ -1,8 +0,0 @@ -//@ run-pass -//@ aux-build:msvc-data-only-lib.rs - -extern crate msvc_data_only_lib; - -fn main() { - println!("The answer is {} !", msvc_data_only_lib::FOO); -} diff --git a/tests/ui/msvc-opt-minsize.rs b/tests/ui/msvc-opt-minsize.rs deleted file mode 100644 index c1be168a05dde..0000000000000 --- a/tests/ui/msvc-opt-minsize.rs +++ /dev/null @@ -1,31 +0,0 @@ -// 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 - -//@ ignore-cross-compile -// Reason: the compiled binary is executed -//@ only-windows -// Reason: the observed bug only occurs on Windows -//@ 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, see issue #45034 - let y: fn(i32, i32) -> i64 = test::black_box(foo); - test::black_box(y(1, 2)); -} - -fn main() { - bar(); -} diff --git a/tests/ui/multibyte.rs b/tests/ui/multibyte.rs deleted file mode 100644 index d585a791fb9c1..0000000000000 --- a/tests/ui/multibyte.rs +++ /dev/null @@ -1,7 +0,0 @@ -//@ run-pass -// - -// Test that multibyte characters don't crash the compiler -pub fn main() { - println!("마이너스 사인이 없으면"); -} diff --git a/tests/ui/multiline-comment.rs b/tests/ui/multiline-comment.rs deleted file mode 100644 index 9817488203221..0000000000000 --- a/tests/ui/multiline-comment.rs +++ /dev/null @@ -1,6 +0,0 @@ -//@ run-pass - -/* - * This is a multi-line oldcomment. - */ -pub fn main() { } diff --git a/tests/ui/parser/multiline-comments-basic.rs b/tests/ui/parser/multiline-comments-basic.rs new file mode 100644 index 0000000000000..1aa2a531f5cc2 --- /dev/null +++ b/tests/ui/parser/multiline-comments-basic.rs @@ -0,0 +1,10 @@ +//! Test that basic multiline comments are parsed correctly. +//! +//! Feature implementation test for . + +//@ run-pass + +/* + * This is a multi-line comment. + */ +pub fn main() {} diff --git a/tests/ui/parser/unicode-multibyte-chars-no-ice.rs b/tests/ui/parser/unicode-multibyte-chars-no-ice.rs new file mode 100644 index 0000000000000..b1bb0c66ae2bb --- /dev/null +++ b/tests/ui/parser/unicode-multibyte-chars-no-ice.rs @@ -0,0 +1,9 @@ +//! Test that multibyte Unicode characters don't crash the compiler. +//! +//! Regression test for . + +//@ run-pass + +pub fn main() { + println!("마이너스 사인이 없으면"); +}