Repository: rust
Issue: Tracking Issue for feature(coroutine_clone)
Labels: T-lang,C-tracking-issue,S-tracking-impl-incomplete,F-coroutine_clone

This is the tracking issue for `#[feature(coroutine_clone)]`.

This feature extends [RFC #2132](https://github.com/rust-lang/rfcs/pull/2132) to allow non-`static` coroutines to implement `Clone`/`Copy` if all their captured variables and all local variables which are held across a yield implement `Clone`/`Copy`. For instance, we can now write code like this:

```rust
let mut coro0 = || {
    yield 0u32;
    yield 1u32;
};
assert_eq!(CoroutineState::Yielded(0u32), Coroutine::resume(Pin::new(&mut coro0), ()));

// Clone a started coroutine in its current state.
let mut coro1 = coro0.clone();

// Both the original and the clone now yield 1.
assert_eq!(CoroutineState::Yielded(1u32), Coroutine::resume(Pin::new(&mut coro0), ()));
assert_eq!(GeneratorState::Yielded(1u32), Coroutine::resume(Pin::new(&mut coro1), ()));
```

This also works if the coroutine captures `Clone` data:

```rust
let data = vec!["first", "second"];
let mut coro0 = move || {
    yield data[0];
    yield data[1];
};
assert_eq!(CoroutineState::Yielded("first"), Coroutine:resume(Pin::new(&mut coro0), ()));

let mut coro1 = coro0.clone();
assert_eq!(CoroutineState::Yielded("second"), Coroutine::resume(Pin::new(&mut coro0), ()));
assert_eq!(CoroutineState::Yielded("second"), Coroutine::resume(Pin::new(&mut coro1), ()));
```

But not if the Coroutine is `static` or contains non-clonable state.

```rust
let coro0 = static || {
    yield 0u32;
    yield 1u32;
};

// ERROR: the trait bound `[static coroutine@...]: Clone` is not satisfied.
let coro1 = coro0.clone();
```

```rust
struct NonClone;

let coro0 = || {
    // NOTE: has type `NonClone` which does not implement `Clone`.
    let non_clone = NonClone;
    yield 0u32;
    drop(non_clone);
}

// ERROR: the trait bound `NonClone: Clone` is not satisified in `[coroutine@...]`
let coro1 = coro0.clone();
```

Since this feature does not allow `static` coroutines to be cloned it does not apply to anonymous futures created using `async` blocks/functions (since these are desugared to `static` coroutines). Allowing these futures to be clonable is an extension worth considering but is outside the scope of this feature.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Implement the RFC
- [ ] Adjust documentation
- [ ] Stabilization PR

### Unresolved Questions

- Cloning a corotuine that has been polled before is akin to that coroutine returning from its `yield` multiple times. This is a non-trivial extension of coroutine semantics, with consequences for MIR analyses and correctness reasoning. Let's make sure to properly discuss and explore the consequences of this before stabilizing anything.

### Implementation history

* [Initial PR.](https://github.com/rust-lang/rust/pull/95137) => [Revived](https://github.com/rust-lang/rust/pull/101673)