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.

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

Precise capturing in traits #131033

Merged
merged 4 commits into from
Oct 10, 2024

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Sep 29, 2024

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:

@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 Sep 29, 2024
@spastorino
Copy link
Member

Looks good to me!

@compiler-errors
Copy link
Member Author

@spastorino, is this waiting on anything else? I didn't see an r=me after rebasing or anything :)

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@spastorino
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Oct 10, 2024

📌 Commit 960ba89 has been approved by spastorino

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 Oct 10, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request 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 pull request 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
Copy link
Member

Needs rebase.

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 10, 2024
@bors
Copy link
Contributor

bors commented Oct 10, 2024

☔ The latest upstream changes (presumably #131263) made this pull request unmergeable. Please resolve the merge conflicts.

@workingjubilee
Copy link
Member

I have done so. It dropped one of the same set of warnings that PR #131263 stripped.

@bors r=spastorino

@bors
Copy link
Contributor

bors commented Oct 10, 2024

📌 Commit 322c4bd has been approved by spastorino

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 10, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request 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
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 10, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#130308 (codegen_ssa: consolidate tied target checks)
 - rust-lang#130538 (Stabilize const `{slice,array}::from_mut`)
 - rust-lang#130741 (rustc_target: Add sme-b16b16 as an explicit aarch64 target feature)
 - rust-lang#131033 (Precise capturing in traits)
 - rust-lang#131442 (Match std `RUSTFLAGS` for host and target for `mir-opt` test suite to fix double std build/rebuilds)
 - rust-lang#131470 (add test infra to explicitely test rustc with autodiff/enzyme disabled)
 - rust-lang#131475 (Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible" )
 - rust-lang#131493 (Avoid redundant sysroot additions to `PATH` when linking)
 - rust-lang#131509 (Update .mailmap)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4f2af12 into rust-lang:master Oct 10, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Oct 10, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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
Development

Successfully merging this pull request may close these issues.

6 participants