Tracking issue for RFC 3617 precise capturing in traits #130044
Assignees
Labels
B-RFC-implemented
Blocker: Approved by a merged RFC and implemented but not stabilized.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
F-precise_capturing_in_traits
`#![feature(precise_capturing_in_traits)]`
F-precise_capturing
`#![feature(precise_capturing)]`
S-tracking-needs-to-bake
Status: The implementation is "complete" but it needs time to bake.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
traviscross
added
T-lang
7 tasks
|
Because I thought I was seeing double for a moment, for future reference, these two issues are related for obvious reasons, but currently... |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 10, 2024
…in-traits, r=spastorino Precise capturing in traits This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work. Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though. I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs. r? types Tracking issue: * rust-lang#130044
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 10, 2024
…in-traits, r=spastorino Precise capturing in traits This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work. Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though. I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs. r? types Tracking issue: * rust-lang#130044
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Oct 10, 2024
…in-traits, r=spastorino Precise capturing in traits This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work. Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though. I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs. r? types Tracking issue: * rust-lang#130044
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 10, 2024
…in-traits, r=spastorino Precise capturing in traits This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work. Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though. I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs. r? types Tracking issue: * rust-lang#130044
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 10, 2024
Rollup merge of rust-lang#131033 - compiler-errors:precise-capturing-in-traits, r=spastorino Precise capturing in traits This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work. Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though. I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs. r? types Tracking issue: * rust-lang#130044
jhpratt
added a commit
to jhpratt/rust
that referenced
this issue
Nov 18, 2024
Check `use<..>` in RPITIT for refinement
`#![feature(precise_capturing_in_traits)]` allows users to write `+ use<>` bounds on RPITITs to control what lifetimes are captured by the RPITIT.
Since RPITITs currently also warn for refinement in implementations, this PR extends that refinement check for cases where we *undercapture* in an implementation, since that may be indirectly "promising" a more relaxed outlives bound than the impl author intended.
For an opaque to be refining, we need to capture *fewer* parameters than those mentioned in the captured params of the trait. For example:
```
trait TypeParam<T> {
fn test() -> impl Sized;
}
// Indirectly capturing a lifetime param through a type param substitution.
impl<'a> TypeParam<&'a ()> for i32 {
fn test() -> impl Sized + use<> {}
//~^ WARN impl trait in impl method captures fewer lifetimes than in trait
}
```
Since the opaque in the method (implicitly) captures `use<Self, T>`, and `Self = i32, T = &'a ()` in the impl, we must mention `'a` in our `use<..>` on the impl.
Tracking:
* rust-lang#130044
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 18, 2024
Rollup merge of rust-lang#132795 - compiler-errors:refine-rpitit, r=lcnr Check `use<..>` in RPITIT for refinement `#![feature(precise_capturing_in_traits)]` allows users to write `+ use<>` bounds on RPITITs to control what lifetimes are captured by the RPITIT. Since RPITITs currently also warn for refinement in implementations, this PR extends that refinement check for cases where we *undercapture* in an implementation, since that may be indirectly "promising" a more relaxed outlives bound than the impl author intended. For an opaque to be refining, we need to capture *fewer* parameters than those mentioned in the captured params of the trait. For example: ``` trait TypeParam<T> { fn test() -> impl Sized; } // Indirectly capturing a lifetime param through a type param substitution. impl<'a> TypeParam<&'a ()> for i32 { fn test() -> impl Sized + use<> {} //~^ WARN impl trait in impl method captures fewer lifetimes than in trait } ``` Since the opaque in the method (implicitly) captures `use<Self, T>`, and `Self = i32, T = &'a ()` in the impl, we must mention `'a` in our `use<..>` on the impl. Tracking: * rust-lang#130044
fmease
added
the
S-tracking-needs-to-bake
This comment has been minimized.
This comment has been minimized.
traviscross
added
the
B-RFC-implemented
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 26, 2025
Rollup merge of rust-lang#138128 - compiler-errors:precise-capturing-in-traits, r=oli-obk,traviscross Stabilize `#![feature(precise_capturing_in_traits)]` # Precise capturing (`+ use<>` bounds) in traits - Stabilization Report Fixes rust-lang#130044. ## Stabilization summary This report proposes the stabilization of `use<>` precise capturing bounds in return-position impl traits in traits (RPITITs). This completes a missing part of [RFC 3617 "Precise capturing"]. Precise capturing in traits was not ready for stabilization when the first subset was proposed for stabilization (namely, RPITs on free and inherent functions - rust-lang#127672) since this feature has a slightly different implementation, and it hadn't yet been implemented or tested at the time. It is now complete, and the type system implications of this stabilization are detailed below. ## Motivation Currently, RPITITs capture all in-scope lifetimes, according to the decision made in the ["lifetime capture rules 2024" RFC](https://rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html#return-position-impl-trait-in-trait-rpitit). However, traits can be designed such that some lifetimes in arguments may not want to be captured. There is currently no way to express this. ## Major design decisions since the RFC No major decisions were made. This is simply an extension to the RFC that was understood as a follow-up from the original stabilization. ## What is stabilized? Users may write `+ use<'a, T>` bounds on their RPITITs. This conceptually modifies the desugaring of the RPITIT to omit the lifetimes that we would copy over from the method. For example, ```rust trait Foo { fn method<'a>(&'a self) -> impl Sized; // ... desugars to something like: type RPITIT_1<'a>: Sized; fn method_desugared<'a>(&'a self) -> Self::RPITIT_1<'a>; // ... whereas with precise capturing ... fn precise<'a>(&'a self) -> impl Sized + use<Self>; // ... desugars to something like: type RPITIT_2: Sized; fn precise_desugared<'a>(&'a self) -> Self::RPITIT_2; } ``` And thus the GAT doesn't name `'a`. In the compiler internals, it's not implemented exactly like this, but not in a way that users should expect to be able to observe. #### Limitations on what generics must be captured Currently, we require that all generics from the trait (including the `Self`) type are captured. This is because the generics from the trait are required to be *invariant* in order to do associated type normalization. And like regular precise capturing bounds, all type and const generics in scope must be captured. Thus, only the in-scope method lifetimes may be relaxed with this syntax today. ## What isn't stabilized? (a.k.a. potential future work) See section above. Relaxing the requirement to capture all type and const generics in scope may be relaxed when rust-lang#130043 is implemented, however it currently interacts with some underexplored corners of the type system (e.g. unconstrained type bivariance) so I don't expect it to come soon after. ## Implementation summary This functionality is implemented analogously to the way that *opaque type* precise capturing works. Namely, we currently use *variance* to model the capturedness of lifetimes. However, since RPITITs are anonymous GATs instead of opaque types, we instead modify the type relation of GATs to consider variances for RPITITs (along with opaque types which it has done since rust-lang#103491). https://github.com/rust-lang/rust/blob/30f168ef811aec63124eac677e14699baa9395bd/compiler/rustc_middle/src/ty/util.rs#L954-L976 https://github.com/rust-lang/rust/blob/30f168ef811aec63124eac677e14699baa9395bd/compiler/rustc_type_ir/src/relate.rs#L240-L244 Using variance to model capturedness is an implementation detail, and in the future it would be desirable if opaques and RPITITs simply did not include the uncaptured lifetimes in their generics. This can be changed in a forwards-compatible way, and almost certainly would not be observable by users (at least not negatively, since it may indeed fix some bugs along the way). ## Tests * Test that the lifetime isn't actually captured: `tests/ui/impl-trait/precise-capturing/rpitit.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives-2.rs`. * Technical test for variance computation: `tests/ui/impl-trait/in-trait/variance.rs`. * Test that you must capture all trait generics: `tests/ui/impl-trait/precise-capturing/forgot-to-capture-type.rs`. * Test that you cannot capture more than what the trait specifies: `tests/ui/impl-trait/precise-capturing/rpitit-captures-more-method-lifetimes.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-impl-captures-too-much.rs`. * Undercapturing (refinement) lint: `tests/ui/impl-trait/in-trait/refine-captures.rs`. ### What other unstable features may be exposed by this feature? I don't believe that this exposes any new unstable features indirectly. ## Remaining bugs and open issues Not aware of any open issues or bugs. ## Tooling support Rustfmt: ✅ Supports formatting `+ use<>` everywhere. Clippy: ✅ No support needed, unless specific clippy lints are impl'd to care for precise capturing itself. Rustdoc: ✅ Rendering `+ use<>` precise capturing bounds is supported. Rust-analyzer: ✅ Parser support, and then lifetime support isn't needed rust-lang#138128 (comment) (previous: ~~:question: There is parser support, but I am unsure of rust-analyzer's level of support for RPITITs in general.~~) ## History Tracking issue: rust-lang#130044 * rust-lang#131033 * rust-lang#132795 * rust-lang#136554
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The feature gate for the issue is
#![feature(precise_capturing_in_traits)].This tracking issue covers extending the
precise_capturingfeature to allow for the partial capturing of generic parameters within trait definitions.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
precise_capturingsyntax #123432Unresolved Questions
TODO.
Implementation History
use<..>in RPITIT for refinement #132795Related
TODO.
cc @compiler-errors
The text was updated successfully, but these errors were encountered: