Rollup merge of #134024 - jieyouxu:ui-cleanup-2, r=Nadrieril

matthiaskrgr · web-flow · commit 1aab767324b8 · 2024-12-08T17:18:53.000+01:00
Advent of `tests/ui` (misc cleanups and improvements) [2/N] Part of #133895. Misc improvements to some ui tests immediately under `tests/ui/`. Best reviewed commit-by-commit. Please see individual commit messages for some further rationale and change summaries. r? compiler
diff --git a/tests/ui/assign-imm-local-twice.rs b/tests/ui/assign-imm-local-twice.rs
diff --git a/tests/ui/assoc-lang-items.rs b/tests/ui/assoc-lang-items.rs
diff --git a/tests/ui/assoc-oddities-3.rs b/tests/ui/assoc-oddities-3.rs
diff --git a/tests/ui/atomic-from-mut-not-available.rs b/tests/ui/atomic-from-mut-not-available.rs
diff --git a/tests/ui/borrowck/assign-imm-local-twice.fixed b/tests/ui/borrowck/assign-imm-local-twice.fixed
@@ -0,0 +1,21 @@
+//! Check that we do not allow assigning twice to an immutable variable. This test also checks a
+//! few pieces of borrowck diagnostics:
+//!
+//! - A multipart borrowck diagnostics that points out the first assignment to an immutable
+//!   variable, alongside violating assignments that follow subsequently.
+//! - A suggestion diagnostics to make the immutable binding mutable.
+
+//@ run-rustfix
+
+fn main() {
+    let mut v: isize;
+    //~^ HELP consider making this binding mutable
+    //~| SUGGESTION mut
+    v = 1;
+    //~^ NOTE first assignment
+    println!("v={}", v);
+    v = 2;
+    //~^ ERROR cannot assign twice to immutable variable
+    //~| NOTE cannot assign twice to immutable
+    println!("v={}", v);
+}
diff --git a/tests/ui/borrowck/assign-imm-local-twice.rs b/tests/ui/borrowck/assign-imm-local-twice.rs
@@ -0,0 +1,21 @@
+//! Check that we do not allow assigning twice to an immutable variable. This test also checks a
+//! few pieces of borrowck diagnostics:
+//!
+//! - A multipart borrowck diagnostics that points out the first assignment to an immutable
+//!   variable, alongside violating assignments that follow subsequently.
+//! - A suggestion diagnostics to make the immutable binding mutable.
+
+//@ run-rustfix
+
+fn main() {
+    let v: isize;
+    //~^ HELP consider making this binding mutable
+    //~| SUGGESTION mut
+    v = 1;
+    //~^ NOTE first assignment
+    println!("v={}", v);
+    v = 2;
+    //~^ ERROR cannot assign twice to immutable variable
+    //~| NOTE cannot assign twice to immutable
+    println!("v={}", v);
+}
diff --git a/tests/ui/borrowck/assign-imm-local-twice.stderr b/tests/ui/borrowck/assign-imm-local-twice.stderr
@@ -1,9 +1,9 @@
 error[E0384]: cannot assign twice to immutable variable `v`
-  --> $DIR/assign-imm-local-twice.rs:7:5
+  --> $DIR/assign-imm-local-twice.rs:17:5
    |
 LL |     v = 1;
    |     ----- first assignment to `v`
-LL |     println!("v={}", v);
+...
 LL |     v = 2;
    |     ^^^^^ cannot assign twice to immutable variable
    |
diff --git a/tests/ui/codegen/assign-expr-unit-type.rs b/tests/ui/codegen/assign-expr-unit-type.rs
@@ -1,5 +1,11 @@
+//! Regression test for [Using the result of an assignment expression results in an LLVM assert
+//! #483][issue-483]. This test checks that assignment expressions produce a unit type, and is
+//! properly lowered to LLVM IR such that it does not trigger an LLVM assertion. This test was added
+//! *really* early, back in 2011.
+//!
+//! [issue-483]: https://github.com/rust-lang/rust/issues/483
+
 //@ run-pass
-// Issue 483 - Assignment expressions result in nil
 
 fn test_assign() {
     let mut x: isize;
@@ -27,4 +33,7 @@ fn test_assign_op() {
     assert_eq!(z, ());
 }
 
-pub fn main() { test_assign(); test_assign_op(); }
+pub fn main() {
+    test_assign();
+    test_assign_op();
+}
diff --git a/tests/ui/lang-items/assoc-lang-items.rs b/tests/ui/lang-items/assoc-lang-items.rs
@@ -0,0 +1,35 @@
+//! Check that associated items can be marked as lang items, so that they don't have to be looked up
+//! by name or by definition order indirectly.
+//!
+//! This test is not *quite* high-fidelity: it checks that you can use lang items on associated
+//! items by looking at the error message *as a proxy*. That is, the error message is about
+//! undefined lang items and not invalid attribute target, indicating that it has reached lang item
+//! machinery (which is relying on knowing the implementation detail). However, it's annoying to
+//! write a full-fidelity test for this, so I think this is acceptable even though it's not *great*.
+//!
+//! This was implemented in <https://github.com/rust-lang/rust/pull/72559> to help with
+//! <https://github.com/rust-lang/rust/issues/70718>, which is itself relevant for e.g. `Fn::Output`
+//! or `Future::Output` or specific use cases like [Use `T`'s discriminant type in
+//! `mem::Discriminant<T>` instead of `u64`](https://github.com/rust-lang/rust/pull/70705).
+
+#![feature(lang_items)]
+
+trait Foo {
+    #[lang = "dummy_lang_item_1"] //~ ERROR definition
+    fn foo() {}
+
+    #[lang = "dummy_lang_item_2"] //~ ERROR definition
+    fn bar();
+
+    #[lang = "dummy_lang_item_3"] //~ ERROR definition
+    type MyType;
+}
+
+struct Bar;
+
+impl Bar {
+    #[lang = "dummy_lang_item_4"] //~ ERROR definition
+    fn test() {}
+}
+
+fn main() {}
diff --git a/tests/ui/lang-items/assoc-lang-items.stderr b/tests/ui/lang-items/assoc-lang-items.stderr
@@ -1,23 +1,23 @@
 error[E0522]: definition of an unknown lang item: `dummy_lang_item_1`
-  --> $DIR/assoc-lang-items.rs:4:5
+  --> $DIR/assoc-lang-items.rs:18:5
    |
 LL |     #[lang = "dummy_lang_item_1"]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ definition of unknown lang item `dummy_lang_item_1`
 
 error[E0522]: definition of an unknown lang item: `dummy_lang_item_2`
-  --> $DIR/assoc-lang-items.rs:7:5
+  --> $DIR/assoc-lang-items.rs:21:5
    |
 LL |     #[lang = "dummy_lang_item_2"]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ definition of unknown lang item `dummy_lang_item_2`
 
 error[E0522]: definition of an unknown lang item: `dummy_lang_item_3`
-  --> $DIR/assoc-lang-items.rs:10:5
+  --> $DIR/assoc-lang-items.rs:24:5
    |
 LL |     #[lang = "dummy_lang_item_3"]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ definition of unknown lang item `dummy_lang_item_3`
 
 error[E0522]: definition of an unknown lang item: `dummy_lang_item_4`
-  --> $DIR/assoc-lang-items.rs:17:5
+  --> $DIR/assoc-lang-items.rs:31:5
    |
 LL |     #[lang = "dummy_lang_item_4"]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ definition of unknown lang item `dummy_lang_item_4`
diff --git a/tests/ui/parser/assoc/assoc-oddities-3.rs b/tests/ui/parser/assoc/assoc-oddities-3.rs
@@ -0,0 +1,41 @@
+//! Check that braces has the expected precedence in relation to index op and some arithmetic
+//! bin-ops involving nested braces.
+//!
+//! This is a regression test for [Wrapping expr in curly braces changes the operator precedence
+//! #28777](https://github.com/rust-lang/rust/issues/28777), which was fixed by
+//! <https://github.com/rust-lang/rust/pull/30375>.
+
+//@ run-pass
+
+fn that_odd_parse(c: bool, n: usize) -> u32 {
+    let x = 2;
+    let a = [1, 2, 3, 4];
+    let b = [5, 6, 7, 7];
+    x + if c { a } else { b }[n]
+}
+
+/// See [Wrapping expr in curly braces changes the operator precedence
+/// #28777](https://github.com/rust-lang/rust/issues/28777). This was fixed by
+/// <https://github.com/rust-lang/rust/pull/30375>. #30375 added the `that_odd_parse` example above,
+/// but that is not *quite* the same original example as reported in #28777, so we also include the
+/// original example here.
+fn check_issue_28777() {
+    // Before #30375 fixed the precedence...
+
+    // ... `v1` evaluated to 9, indicating a parse of `(1 + 2) * 3`, while
+    let v1 = { 1 + { 2 } * { 3 } };
+
+    // `v2` evaluated to 7, indicating a parse of `1 + (2 * 3)`.
+    let v2 = 1 + { 2 } * { 3 };
+
+    // Check that both now evaluate to 7, as was fixed by #30375.
+    assert_eq!(v1, 7);
+    assert_eq!(v2, 7);
+}
+
+fn main() {
+    assert_eq!(4, that_odd_parse(true, 1));
+    assert_eq!(8, that_odd_parse(false, 1));
+
+    check_issue_28777();
+}
diff --git a/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.alignment_matches.stderr b/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.alignment_matches.stderr
@@ -0,0 +1,13 @@
+error[E0658]: use of unstable library feature `atomic_from_mut`
+  --> $DIR/atomic-from-mut-not-available.rs:24:5
+   |
+LL |     core::sync::atomic::AtomicU64::from_mut(&mut 0u64);
+   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   |
+   = note: see issue #76314 <https://github.com/rust-lang/rust/issues/76314> for more information
+   = help: add `#![feature(atomic_from_mut)]` to the crate attributes to enable
+   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
+
+error: aborting due to 1 previous error
+
+For more information about this error, try `rustc --explain E0658`.
diff --git a/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.alignment_mismatch.stderr b/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.alignment_mismatch.stderr
@@ -1,5 +1,5 @@
 error[E0599]: no function or associated item named `from_mut` found for struct `AtomicU64` in the current scope
-  --> $DIR/atomic-from-mut-not-available.rs:5:36
+  --> $DIR/atomic-from-mut-not-available.rs:24:36
    |
 LL |     core::sync::atomic::AtomicU64::from_mut(&mut 0u64);
    |                                    ^^^^^^^^ function or associated item not found in `AtomicU64`
diff --git a/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.rs b/tests/ui/stdlib-unit-tests/atomic-from-mut-not-available.rs
@@ -0,0 +1,27 @@
+//! This test exercises the combined effect of the `cfg(target_has_atomic_equal_alignment = "...")`
+//! implementation in the compiler plus usage of said `cfg(target_has_atomic_equal_alignment)` in
+//! `core` for the `Atomic64::from_mut` API.
+//!
+//! This test is a basic smoke test: that `AtomicU64::from_mut` is gated by
+//! `#[cfg(target_has_atomic_equal_alignment = "8")]`, which is only available on platforms where
+//! `AtomicU64` has the same alignment as `u64`. This is notably *not* satisfied by `x86_32`, where
+//! they have differing alignments. Thus, `AtomicU64::from_mut` should *not* be available on
+//! `x86_32` linux and should report assoc item not found, if the `cfg` is working correctly.
+//! Conversely, `AtomicU64::from_mut` *should* be available on `x86_64` linux where the alignment
+//! matches.
+
+//@ revisions: alignment_mismatch alignment_matches
+
+// This should fail on 32-bit x86 linux...
+//@[alignment_mismatch] only-x86
+//@[alignment_mismatch] only-linux
+
+// ... but pass on 64-bit x86_64 linux.
+//@[alignment_matches] only-x86_64
+//@[alignment_matches] only-linux
+
+fn main() {
+    core::sync::atomic::AtomicU64::from_mut(&mut 0u64);
+    //[alignment_mismatch]~^ ERROR no function or associated item named `from_mut` found for struct `AtomicU64`
+    //[alignment_matches]~^^ ERROR use of unstable library feature `atomic_from_mut`
+}

Original file line number	Diff line number	Diff line change
`@@ -1,9 +1,9 @@`
`1`	`1`	error[E0384]: cannot assign twice to immutable variable `v`
`2`		`- --> $DIR/assign-imm-local-twice.rs:7:5`
	`2`	`+ --> $DIR/assign-imm-local-twice.rs:17:5`
`3`	`3`	`\|`
`4`	`4`	`LL \| v = 1;`
`5`	`5`	\| ----- first assignment to `v`
`6`		`-LL \| println!("v={}", v);`
	`6`	`+...`
`7`	`7`	`LL \| v = 2;`
`8`	`8`	`\| ^^^^^ cannot assign twice to immutable variable`
`9`	`9`	`\|`