Files
rust/tests/ui
Matthias Krüger ee73660368 Rollup merge of #123660 - compiler-errors:coroutine-closure-env, r=oli-obk
Make the computation of `coroutine_captures_by_ref_ty` more sophisticated

Currently, we treat all the by-(mut/)ref borrows of a coroutine-closure as having a "closure env" borrowed lifetime.

When we have the given code:
```rust
let x: &'a i32 = ...;
let c = async || {
    let _x = *x;
};
```

Then when we call:
```rust
c()
// which, because `AsyncFn` takes a `&self`, we insert an autoref:
(&c /* &'env {coroutine-closure} */)()
```

We will return a future whose captures contain `&'env i32` instead of `&'a i32`, which is way more restrictive than necessary. We should be able to drop `c` while the future is alive since it's not actually borrowing any data *originating from within* the closure's captures, but since the capture has that `'env` lifetime, this is not possible.

This wouldn't be true, for example, if the closure captured `i32` instead of `&'a i32`, because the `'env` lifetime is actually *necessary* since the data (`i32`) is owned by the closure.

This PR identifies two criteria where we *need* to take the borrow with the closure env lifetime:
1. If the closure borrows data from inside the closure's captures. This is not true if the parent capture is by-ref, OR if the parent capture is by-move and the child capture begins with a deref projection. This is the example described above.
2. If we're dealing with mutable references, since we cannot reborrow `&'env mut &'a mut i32` into `&'a mut i32`, *only* `&'env mut i32`.

See the documentation on `should_reborrow_from_env_of_parent_coroutine_closure` for more info.

**important:** As disclaimer states on that function, luckily, if this heuristic is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.

Fixes #123241
2024-04-11 16:57:40 +02:00
..
2024-04-07 01:16:45 +02:00
2024-03-15 13:37:41 +00:00
2024-02-01 03:31:03 +00:00
2024-03-03 16:30:48 -03:00
2024-03-06 12:01:54 +00:00
2024-03-28 06:00:25 +00:00
2024-04-04 01:55:29 +01:00
2024-04-03 22:48:55 +01:00
2024-04-07 17:38:07 -03:00
2024-04-07 17:38:07 -03:00
2024-03-27 11:20:28 -04:00
2024-04-07 01:16:45 +02:00
2024-03-24 09:19:29 +01:00
2024-03-23 16:14:42 +01:00
2024-04-07 17:38:07 -03:00
2024-02-29 14:43:43 +01:00
2024-03-31 14:58:17 -03:00
2024-04-09 01:19:43 +02:00
2024-03-27 09:53:23 -04:00
2024-03-15 13:37:41 +00:00
2024-03-12 10:59:41 +01:00
2024-04-07 17:38:07 -03:00
2024-04-06 15:14:16 -04:00
2024-04-04 02:14:57 +01:00
2024-02-22 18:05:28 +00:00
2024-01-13 12:46:58 -05:00
2024-02-07 10:42:01 +08:00
2024-01-13 12:46:58 -05:00
2024-01-13 12:46:58 -05:00
2024-02-07 10:42:01 +08:00

UI Tests

This folder contains rustc's UI tests.

Test Directives (Headers)

Typically, a UI test will have some test directives / headers which are special comments that tell compiletest how to build and intepret a test.

As part of an on-going effort to rewrite compiletest (see https://github.com/rust-lang/compiler-team/issues/536), a major change proposal to change legacy compiletest-style headers // <directive> to ui_test-style headers //@ <directive> was accepted (see https://github.com/rust-lang/compiler-team/issues/512.

An example directive is ignore-test. In legacy compiletest style, the header would be written as

// ignore-test

but in ui_test style, the header would be written as

//@ ignore-test

compiletest is changed to accept only //@ directives for UI tests (currently), and will reject and report an error if it encounters any comments // <content> that may be parsed as an legacy compiletest-style test header. To fix this, you should migrate to the ui_test-style header //@ <content>.