-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for RFC 2093: Infer T: 'x
outlives requirements on structs
#44493
Comments
Mentoring instructionsIn the compiler, when we want to know what predicates are defined on something (e.g., a struct), we do that via the In terms of how to fit this inference into the compiler pipeline, then, I think we want to ensure that
The very first PR, then, could be to introduce the Now we have to figure out how to implemented
The The reason for this particular setup is that we can't infer the variances for a single item in isolation; the variance for an item X depends on the contents of the struct, and there may be cycles. Since cycles are generally forbidden between queries, we instead compute the variances for ALL structs in the crate, and then use individual queries to extract the result. So, for This crate-wide computation will work much as it is described in the RFC -- there will be a set of constraints being inferred for each struct Next, we can walk the types of the fields declared in each struct. These can be obtained by invoking Once this is done, we should have some kind of inferred set of obligations for each struct. I think it'd be good to setup a unit-testing mechanism for this similar to the one we use for variance. Basically, some custom code that looks for a So, in terms of first steps, these are good PRs to open:
|
I would like to work on this! |
@toidiu hey, just checking in! I just r+'d that first PR, wondering if you'd had any time to mess around with the next few steps? |
@nikomatsakis hey sry for the slow progress. I have have mainly been trying to wrap my head around all the different concepts and the repo structure. Have read the mentoring guide and rfc a few times now I am hoping to make some initial pr's early this week. |
Infer `T: 'x` outlives requirements on structs rust-lang#44493 rust-lang#44493
Pseudocode of how the inference wants to work, I think:
|
@toidiu Are you still working on this? If not, I'd be interested in taking a jab at this issue. |
@Yoric yea still making progress and iterating on one PR so as not to queue up bors |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
Let's get this stabilized, then! There are instructions for how to do so here: https://forge.rust-lang.org/stabilization-guide.html @toidiu — you would be up for that? You've seen this thing through from start to finish thus far! |
I think we should also split off a new issue for the |
@nikomatsakis yep would be glad to :) |
visiting for triage. PR #53793 is meant to resolve this. |
stabilize outlives requirements #44493 r? @nikomatsakis
visiting for triage. #53793 landed. closing as fixed. |
Created #54185 to track the |
#52042 already exists to track an idiom lint |
RFC 2093 (tracking issue rust-lang#44493) lets us leave off commonsensically inferable `T: 'a` outlives requirements. (A separate feature-gate was split off for the case of 'static lifetimes, for which questions still remain.) Detecting these was requested as an idioms-2018 lint. It turns out that issuing a correct, autofixable suggestion here is somewhat subtle in the presence of other bounds and generic parameters. Basically, we want to handle these three cases: • One outlives-bound. We want to drop the bound altogether, including the colon— MyStruct<'a, T: 'a> ^^^^ help: remove this bound • An outlives bound first, followed by a trait bound. We want to delete the outlives bound and the following plus sign (and hopefully get the whitespace right, too)— MyStruct<'a, T: 'a + MyTrait> ^^^^^ help: remove this bound • An outlives bound after a trait bound. We want to delete the outlives lifetime and the preceding plus sign— MyStruct<'a, T: MyTrait + 'a> ^^^^^ help: remove this bound This gets (slightly) even more complicated in the case of where clauses, where we want to drop the where clause altogether if there's just the one bound. Hopefully the comments are enough to explain what's going on! A script (in Python, sorry) was used to generate the hopefully-sufficiently-exhaustive UI test input. Some of these are split off into a different file because rust-lang/rustfix#141 (and, causally upstream of that, rust-lang#53934) prevents them from being `run-rustfix`-tested. We also make sure to include a UI test of a case (copied from RFC 2093) where the outlives-bound can't be inferred. Special thanks to Niko Matsakis for pointing out the `inferred_outlives_of` query, rather than blindly stripping outlives requirements as if we weren't a production compiler and didn't care. This concerns rust-lang#52042.
in which inferable outlives-requirements are linted RFC 2093 (tracking issue #44493) lets us leave off these commonsensically inferable `T: 'a` outlives requirements. (A separate feature-gate was split off for the case of 'static lifetimes, for which questions still remain.) Detecting these was requested as an idioms-2018 lint. Resolves #52042, an item under the fabulous metaïssue #52047. It's plausible that this shouldn't land until after `infer_outlives_requirements` has been stabilized ([final comment period started](#44493 (comment)) 4 days ago), but I think there's also a strong case to not-wait in order to maximize the time that [Edition Preview 2](https://internals.rust-lang.org/t/rust-2018-release-schedule-and-extended-beta/8076) users have to kick at it. (It's allow by default, so there's no impact unless you explicitly turn it or the rust-2018-idioms group up to `warn` or higher.) Questions— * Is `explicit-outlives-requirements` a good name? (I chose it as an [RFC 344](https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints)-compliant "inversion" of the feature-gate name, `infer_outlives_requirements`, but I could imagine someone arguing that the word `struct` should be part of the name somewhere, for specificity.) * Are there any false-positives or false-negatives? @nikomatsakis [said that](#52042 (comment)) getting this right would be "fairly hard", which makes me nervous that I'm missing something. The UI test in the initial submission of this pull request just exercises the examples [given in the Edition Guide](https://rust-lang-nursery.github.io/edition-guide/2018/transitioning/ownership-and-lifetimes/struct-inference.html). ![infer_outlints](https://user-images.githubusercontent.com/1076988/43625740-6bf43dca-96a3-11e8-9dcf-793ac83d424d.png) r? @alexcrichton
reasons: 1. This annotation is no longer needed since it can be inferred from the fields present in the definitions in Rust 2018. 2. `T: 'a` annotation is never mentioned in previous chapters, this would make beinners confused. references: rust-lang/rfcs#2093 rust-lang/rust#44493 https://rust-lang-nursery.github.io/edition-guide/rust-2018/ownership-and-lifetimes/inference-in-structs.html
#54185 (comment) ended the question about whether to special-case |
stabilize outlives requirements rust-lang/rust#44493 r? @nikomatsakis
This is a tracking issue for the RFC "Infer
T: 'x
outlives requirements on structs " (rust-lang/rfcs#2093).Current status:
Implemented and we have decided to stabilize. We still need someone to make the stabilization PR! Mentoring instructions here:
https://github.com/rust-lang/rust/issue_comments#issuecomment-411781121
Until then, you can use this by adding
#![feature(infer_outlives_requirements)]
to your crate.Steps:
Unresolved questions:
The interaction with
'static
remains a bit unclear. For example, do we want to infer aT: 'static
requirement on the type parameterT
here? The code currently will do so, arguably leading to confusing errors.The text was updated successfully, but these errors were encountered: