Skip to content

Commit 1e3a2b2

Browse files
committed
cleaned up some tests
1 parent a38c78c commit 1e3a2b2

File tree

5 files changed

+57
-33
lines changed

5 files changed

+57
-33
lines changed
Lines changed: 21 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,20 @@
1-
//@ run-pass
1+
//! Test that monomorphization correctly distinguishes types with different ABI alignment.
2+
//!
3+
//! On x86_64-linux-gnu and similar platforms, structs get 8-byte "preferred"
4+
//! alignment, but their "ABI" alignment (what actually matters for data layout)
5+
//! is the largest alignment of any field. If monomorphization incorrectly uses
6+
//! "preferred" alignment instead of "ABI" alignment, it might unify types `A`
7+
//! and `B` even though `S<A>` and `S<B>` have field `t` at different offsets,
8+
//! leading to incorrect method dispatch for `unwrap()`.
29
3-
#![allow(non_upper_case_globals)]
4-
#![allow(dead_code)]
5-
/*!
6-
* On x86_64-linux-gnu and possibly other platforms, structs get 8-byte "preferred" alignment,
7-
* but their "ABI" alignment (i.e., what actually matters for data layout) is the largest alignment
8-
* of any field. (Also, `u64` has 8-byte ABI alignment; this is not always true).
9-
*
10-
* On such platforms, if monomorphize uses the "preferred" alignment, then it will unify
11-
* `A` and `B`, even though `S<A>` and `S<B>` have the field `t` at different offsets,
12-
* and apply the wrong instance of the method `unwrap`.
13-
*/
10+
//@ run-pass
1411

1512
#[derive(Copy, Clone)]
16-
struct S<T> { i:u8, t:T }
13+
struct S<T> {
14+
#[allow(dead_code)]
15+
i: u8,
16+
t: T,
17+
}
1718

1819
impl<T> S<T> {
1920
fn unwrap(self) -> T {
@@ -22,14 +23,15 @@ impl<T> S<T> {
2223
}
2324

2425
#[derive(Copy, Clone, PartialEq, Debug)]
25-
struct A((u32, u32));
26+
struct A((u32, u32)); // Different ABI alignment than B
2627

2728
#[derive(Copy, Clone, PartialEq, Debug)]
28-
struct B(u64);
29+
struct B(u64); // Different ABI alignment than A
2930

3031
pub fn main() {
31-
static Ca: S<A> = S { i: 0, t: A((13, 104)) };
32-
static Cb: S<B> = S { i: 0, t: B(31337) };
33-
assert_eq!(Ca.unwrap(), A((13, 104)));
34-
assert_eq!(Cb.unwrap(), B(31337));
32+
static CA: S<A> = S { i: 0, t: A((13, 104)) };
33+
static CB: S<B> = S { i: 0, t: B(31337) };
34+
35+
assert_eq!(CA.unwrap(), A((13, 104)));
36+
assert_eq!(CB.unwrap(), B(31337));
3537
}

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

Lines changed: 13 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,18 @@
1-
// A previously outdated version of LLVM caused compilation failures on Windows
2-
// specifically with optimization level `z`. After the update to a more recent LLVM
3-
// version, this test checks that compilation and execution both succeed.
4-
// See https://github.com/rust-lang/rust/issues/45034
1+
//! Test that opt-level=z produces correct code on Windows MSVC targets.
2+
//!
3+
//! A previously outdated version of LLVM caused compilation failures and
4+
//! generated invalid code on Windows specifically with optimization level `z`.
5+
//! The bug manifested as corrupted base pointers due to incorrect register
6+
//! usage in the generated assembly (e.g., `popl %esi` corrupting local variables).
7+
//! After updating to a more recent LLVM version, this test ensures that
8+
//! compilation and execution both succeed with opt-level=z.
9+
//!
10+
//! Regression test for <https://github.com/rust-lang/rust/issues/45034>.
511
612
//@ ignore-cross-compile
713
// Reason: the compiled binary is executed
814
//@ only-windows
9-
// Reason: the observed bug only occurs on Windows
15+
// Reason: the observed bug only occurred on Windows MSVC targets
1016
//@ run-pass
1117
//@ compile-flags: -C opt-level=z
1218

@@ -20,8 +26,8 @@ fn foo(x: i32, y: i32) -> i64 {
2026
#[inline(never)]
2127
fn bar() {
2228
let _f = Box::new(0);
23-
// This call used to trigger an LLVM bug in opt-level z where the base
24-
// pointer gets corrupted, see issue #45034
29+
// This call used to trigger an LLVM bug in opt-level=z where the base
30+
// pointer gets corrupted due to incorrect register allocation
2531
let y: fn(i32, i32) -> i64 = test::black_box(foo);
2632
test::black_box(y(1, 2));
2733
}
Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,18 @@
1+
//! Test that static data from external crates can be imported on MSVC targets.
2+
//!
3+
//! On Windows MSVC targets, static data from external rlibs must be imported
4+
//! through `__imp_<symbol>` stubs to ensure proper linking. Without this,
5+
//! the linker would fail with "unresolved external symbol" errors when trying
6+
//! to reference static data from another crate.
7+
//!
8+
//! Regression test for <https://github.com/rust-lang/rust/issues/26591>.
9+
//! Fixed in <https://github.com/rust-lang/rust/pull/28646>.
10+
111
//@ run-pass
2-
//@ aux-build:msvc-data-only-lib.rs
12+
//@ aux-build:msvc-static-data-import-lib.rs
313

4-
extern crate msvc_data_only_lib;
14+
extern crate msvc_static_data_import_lib;
515

616
fn main() {
7-
println!("The answer is {} !", msvc_data_only_lib::FOO);
17+
println!("The answer is {}!", msvc_static_data_import_lib::FOO);
818
}
Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,10 @@
1+
//! Test that basic multiline comments are parsed correctly.
2+
//!
3+
//! Feature implementation test for <https://github.com/rust-lang/rust/issues/66>.
4+
15
//@ run-pass
26

37
/*
4-
* This is a multi-line oldcomment.
8+
* This is a multi-line comment.
59
*/
6-
pub fn main() { }
10+
pub fn main() {}
Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,9 @@
1+
//! Test that multibyte Unicode characters don't crash the compiler.
2+
//!
3+
//! Regression test for <https://github.com/rust-lang/rust/issues/4780>.
4+
15
//@ run-pass
2-
//
36

4-
// Test that multibyte characters don't crash the compiler
57
pub fn main() {
68
println!("마이너스 사인이 없으면");
79
}

0 commit comments

Comments
 (0)