Check `use<..>` in RPITIT for refinement #132795

compiler-errors · 2024-11-09T01:03:33Z

#![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:

Tracking issue for RFC 3617 precise capturing in traits #130044

rustbot · 2024-11-09T01:03:41Z

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

compiler-errors · 2024-11-09T01:08:18Z

I am aware of one shortcoming of the existing refinement check (not really related to this PR): when we detect a mismatch in trait bounds¹, we will render the opaque from the trait in order to give a suggestion. This rendered opaque will not have its use<..> bounds, for two reasons: it's not a real trait bound, and it doesn't really "make sense" to substitute a use<'a, T> bound with the impl trait ref substitutions.

I'm just acknowledging it here since I do not want to fix it. The refinement check is annoying enough as is.

That is, the existing check, not the one I'm implementing in this PR. ↩

lcnr · 2024-11-13T23:37:26Z

compiler/rustc_hir_analysis/messages.ftl

@@ -448,6 +448,11 @@ hir_analysis_rpitit_refined = impl trait in impl method signature does not match
    .note = add `#[allow(refining_impl_trait)]` if it is intended for this to be part of the public API of this crate
    .feedback_note = we are soliciting feedback, see issue #121718 <https://github.com/rust-lang/rust/issues/121718> for more information

+hir_analysis_rpitit_refined_lifetimes = impl trait in impl method captures fewer lifetimes than in trait
+    .suggestion = add a `use<..>` bound to capture the same lifetimes that the trait does


we already have a use bound 🤔 maybe "modify the use bound..."

lcnr

r=me after nit

compiler-errors · 2024-11-18T00:27:59Z

@bors r=lcnr rollup

bors · 2024-11-18T00:28:01Z

📌 Commit 32d2340 has been approved by lcnr

It is now in the queue for this repository.

Rollup of 7 pull requests Successful merges: - rust-lang#132795 (Check `use<..>` in RPITIT for refinement) - rust-lang#132944 (add parentheses when unboxing suggestion needed) - rust-lang#132993 (Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1`) - rust-lang#133130 (`suggest_borrow_generic_arg`: instantiate clauses properly) - rust-lang#133133 (rustdoc-search: add standalone trailing `::` test) - rust-lang#133143 (Diagnostics for let mut in item context) - rust-lang#133147 (Fixup some test directives) r? `@ghost` `@rustbot` modify labels: rollup

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

…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

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

rustbot assigned lcnr Nov 9, 2024

rustbot added S-waiting-on-review T-compiler labels Nov 9, 2024

lcnr reviewed Nov 13, 2024

View reviewed changes

traviscross added the F-precise_capturing_in_traits label Nov 14, 2024

Check use<..> in RPITIT for refinement

32d2340

compiler-errors force-pushed the refine-rpitit branch from a6f2821 to 32d2340 Compare November 18, 2024 00:27

bors added S-waiting-on-bors and removed S-waiting-on-review labels Nov 18, 2024

jhpratt mentioned this pull request Nov 18, 2024

Rollup of 7 pull requests #133152

Merged

bors merged commit e2993cd into rust-lang:master Nov 18, 2024
6 checks passed

rustbot added this to the 1.84.0 milestone Nov 18, 2024

obi1kenobi mentioned this pull request Dec 6, 2024

SemVer: Add section on RPIT capturing rust-lang/cargo#14849

Merged

fmease mentioned this pull request Dec 12, 2024

Tracking issue for RFC 3617 precise capturing in traits #130044

Closed

7 tasks

compiler-errors mentioned this pull request Mar 6, 2025

Stabilize #![feature(precise_capturing_in_traits)] #138128

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Check `use<..>` in RPITIT for refinement #132795

Check `use<..>` in RPITIT for refinement #132795

compiler-errors commented Nov 9, 2024 •

edited

Loading

rustbot commented Nov 9, 2024

compiler-errors commented Nov 9, 2024 •

edited

Loading

lcnr Nov 13, 2024

compiler-errors Nov 18, 2024

lcnr left a comment

compiler-errors commented Nov 18, 2024

bors commented Nov 18, 2024

Check use<..> in RPITIT for refinement #132795

Check use<..> in RPITIT for refinement #132795

Conversation

compiler-errors commented Nov 9, 2024 • edited Loading

rustbot commented Nov 9, 2024

compiler-errors commented Nov 9, 2024 • edited Loading

Footnotes

lcnr Nov 13, 2024

Choose a reason for hiding this comment

compiler-errors Nov 18, 2024

Choose a reason for hiding this comment

lcnr left a comment

Choose a reason for hiding this comment

compiler-errors commented Nov 18, 2024

bors commented Nov 18, 2024

Check `use<..>` in RPITIT for refinement #132795

Check `use<..>` in RPITIT for refinement #132795

compiler-errors commented Nov 9, 2024 •

edited

Loading

compiler-errors commented Nov 9, 2024 •

edited

Loading