Skip to content

tests/ui: A New Order [14/N] #142440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
4 changes: 0 additions & 4 deletions src/tools/tidy/src/issues.txt
Original file line number Diff line number Diff line change
Expand Up @@ -276,7 +276,6 @@ ui/auto-traits/issue-23080-2.rs
ui/auto-traits/issue-23080.rs
ui/auto-traits/issue-83857-ub.rs
ui/auto-traits/issue-84075.rs
ui/auxiliary/issue-16822.rs
ui/bench/issue-32062.rs
ui/binding/issue-40402-1.rs
ui/binding/issue-40402-2.rs
Expand Down Expand Up @@ -1371,9 +1370,6 @@ ui/intrinsics/issue-28575.rs
ui/intrinsics/issue-84297-reifying-copy.rs
ui/invalid/issue-114435-layout-type-err.rs
ui/issue-11881.rs
ui/issue-15924.rs
ui/issue-16822.rs
ui/issues-71798.rs
ui/issues/auxiliary/issue-11224.rs
ui/issues/auxiliary/issue-11508.rs
ui/issues/auxiliary/issue-11529.rs
Expand Down
Original file line number Diff line number Diff line change
@@ -1,3 +1,7 @@
//! Regression test for issue https://github.com/rust-lang/rust/issues/71798
// ICE with escaping bound variables when impl Future + '_
// returns non-Future type combined with syntax errors

fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ {
//~^ ERROR `u32` is not a future
*x
Expand Down
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
error[E0425]: cannot find value `u` in this scope
--> $DIR/issues-71798.rs:7:24
--> $DIR/impl-future-escaping-bound-vars-ice.rs:11:24
|
LL | let _ = test_ref & u;
| ^ not found in this scope

error[E0277]: `u32` is not a future
--> $DIR/issues-71798.rs:1:25
--> $DIR/impl-future-escaping-bound-vars-ice.rs:5:25
|
LL | fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `u32` is not a future
Expand Down
39 changes: 39 additions & 0 deletions tests/ui/closures/closure-capture-after-clone.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
//! Regression test for issue #1399
//!
//! This test ensures that when a variable is used (via clone) and then later
//! captured by a closure, the last-use analyzer doesn't incorrectly optimize
//! the earlier use as a "last use" and perform an invalid move.
//!
//! The sequence being tested:
//! 1. Create variable `k`
//! 2. Use `k.clone()` for some purpose
//! 3. Later capture `k` in a closure
//!
//! The analyzer must not treat step 2 as the "last use" since step 3 needs `k`.
//!
//! See: https://github.com/rust-lang/rust/issues/1399

//@ run-pass

struct A {
_a: Box<isize>
}

pub fn main() {
fn invoke<F>(f: F)
where
F: FnOnce()
{
f();
}

let k: Box<_> = 22.into();

// This clone should NOT be treated as "last use" of k
// even though k is not used again until the closure
let _u = A { _a: k.clone() };

// Here k is actually captured by the closure
// The last-use analyzer must have accounted for this when processing the clone above
invoke(|| println!("{}", k.clone()));
}
33 changes: 33 additions & 0 deletions tests/ui/closures/closure-last-use-move.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
//! Regression test for issue #1818
//! last-use analysis in closures should allow moves instead of requiring copies.
//!
//! The original issue was that the compiler incorrectly flagged certain return values
//! in anonymous functions/closures as requiring copies of non-copyable values, when
//! they should have been treated as moves (since they were the last use of the value).
//!
//! See: https://github.com/rust-lang/rust/issues/1818

//@ run-pass

fn apply<T, F>(s: String, mut f: F) -> T
where
F: FnMut(String) -> T
{
fn g<T, F>(s: String, mut f: F) -> T
where
F: FnMut(String) -> T
{
f(s)
}

g(s, |v| {
let r = f(v);
r // This should be a move, not requiring copy
})
}

pub fn main() {
// Actually test the functionality
let result = apply(String::from("test"), |s| s.len());
assert_eq!(result, 4);
}
32 changes: 32 additions & 0 deletions tests/ui/closures/closure-upvar-last-use-analysis.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
//! Regression test for issue #1399
//!
//! This test ensures that the compiler's last-use analysis correctly handles variables
//! that are captured by closures (upvars). The original issue was that the analyzer
//! would incorrectly optimize variable usage as "last use" and perform moves, even when
//! the variable was later needed by a closure that captured it.
//!
//! See: https://github.com/rust-lang/rust/issues/1399

//@ run-pass

struct A {
_a: Box<isize>
}

fn foo() -> Box<dyn FnMut() -> isize + 'static> {
let k: Box<_> = Box::new(22);

// This use of k.clone() should not be treated as a "last use"
// even though the closure below doesn't actually capture k
let _u = A { _a: k.clone() };

// The closure doesn't actually use k, but the analyzer needs to handle
// the potential capture scenario correctly
let result = || 22;

Box::new(result)
}

pub fn main() {
assert_eq!(foo()(), 22);
}
39 changes: 39 additions & 0 deletions tests/ui/cross-crate/cross-crate-refcell-match.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
//! Regression test for https://github.com/rust-lang/rust/issues/16822
//
//! ICE when using RefCell::borrow_mut()
//! inside match statement with cross-crate generics.
//!
//! The bug occurred when:
//! - A library defines a generic struct with RefCell<T> and uses borrow_mut() in match
//! - Main crate implements the library trait for its own type
//! - Cross-crate generic constraint causes type inference issues
//!
//! The problematic match statement is in the auxiliary file, this file triggers it.
//! Original error: assertion failed in ty.rs:2481 during type inference.

//@ run-pass
//@ aux-build:cross-crate-refcell-match.rs

extern crate cross_crate_refcell_match as lib;

use std::cell::RefCell;

struct App {
i: isize,
}

impl lib::Update for App {
fn update(&mut self) {
self.i += 1;
}
}

fn main() {
let app = App { i: 5 };
let window = lib::Window {
data: RefCell::new(app),
};
// This specific pattern (RefCell::borrow_mut in match with cross-crate generics)
// caused the ICE in the original issue
window.update(1);
}
12 changes: 12 additions & 0 deletions tests/ui/cross-crate/metadata-trait-serialization.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
//! Test that trait information (like Copy) is correctly serialized in crate metadata

//@ run-pass
//@ aux-build:kinds_in_metadata.rs

extern crate kinds_in_metadata;

use kinds_in_metadata::f;

pub fn main() {
f::<isize>();
}
52 changes: 0 additions & 52 deletions tests/ui/issue-15924.rs
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: i mistakenly deleted issue-15924.rs (#15924) thinking it didn't reproduce the original problem. Should I restore it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the only reason i'm asking is because of this comment #15924 (comment), seems like there is no way to reproduce this anymore because of "new interface scheme", making the regression test potentially obsolete

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, regression tests should err on the side of sticking around. Not being able to reproduce is a good thing - but just because the code is refactored doesn't mean a new design can't hit the same problems.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so preferably to keep this test?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO a solid choice when in doubt :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure! thanks for the answer ;)

This file was deleted.

22 changes: 0 additions & 22 deletions tests/ui/issue-16822.rs

This file was deleted.

16 changes: 0 additions & 16 deletions tests/ui/item-name-overload.rs

This file was deleted.

16 changes: 0 additions & 16 deletions tests/ui/kinds-in-metadata.rs

This file was deleted.

26 changes: 0 additions & 26 deletions tests/ui/kinds-of-primitive-impl.rs

This file was deleted.

21 changes: 0 additions & 21 deletions tests/ui/last-use-in-block.rs

This file was deleted.

17 changes: 0 additions & 17 deletions tests/ui/last-use-in-cap-clause.rs

This file was deleted.

13 changes: 0 additions & 13 deletions tests/ui/last-use-is-capture.rs

This file was deleted.

Loading
Loading