Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 1 commit into from
Nov 18, 2024
Merged

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

merged 1 commit into from
Nov 18, 2024

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Nov 9, 2024 •
edited
Loading

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

@rustbot
Copy link
Collaborator

rustbot commented Nov 9, 2024

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 9, 2024
@compiler-errors
Copy link
Member Author

compiler-errors commented Nov 9, 2024 •
edited
Loading

I am aware of one shortcoming of the existing refinement check (not really related to this PR): when we detect a mismatch in trait bounds1, 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.

Footnotes

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

lcnr
lcnr reviewed Nov 13, 2024
View reviewed changes
compiler/rustc_hir_analysis/messages.ftl Outdated
@@ -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
Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

whoops

lcnr
lcnr reviewed Nov 13, 2024
View reviewed changes
Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

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

r=me after nit

@traviscross traviscross added the F-precise_capturing_in_traits `#![feature(precise_capturing_in_traits)]` label Nov 14, 2024
@compiler-errors
Copy link
Member Author

@bors r=lcnr rollup

@bors
Copy link
Contributor

bors commented Nov 18, 2024

📌 Commit 32d2340 has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 18, 2024
@jhpratt jhpratt mentioned this pull request Nov 18, 2024
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 18, 2024
@bors
Auto merge of rust-lang#133152 - jhpratt:rollup-wkqs5ud, r=jhpratt
bf6adec 
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
@bors bors merged commit e2993cd into rust-lang:master Nov 18, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Nov 18, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 18, 2024
@rust-timer
Unrolled build for rust-lang#132795
0f3042b 
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
@obi1kenobi obi1kenobi mentioned this pull request Dec 6, 2024
Merged
@fmease fmease mentioned this pull request Dec 12, 2024
Open
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lcnr lcnr lcnr left review comments

Assignees

@lcnr lcnr

Labels
F-precise_capturing_in_traits `#![feature(precise_capturing_in_traits)]` S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.84.0
Development

Successfully merging this pull request may close these issues.
5 participants
@compiler-errors @rustbot @bors @lcnr @traviscross