-
Notifications
You must be signed in to change notification settings - Fork 13k
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
internally change regions to be covariant #107339
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice 👍
please also update it in the region solver though as we still flip the variance of regions there right now
I've updated the PR description.
I think that can be an issue for a separate PR. For now, |
might impact perf @bors try
I don't think I am not too convinced that there is a meaningful difference between If you don't intend to work on changing r=me after perf |
⌛ Trying commit 43cb610 with merge b5d497c598ccc0e78ce7392fced08b711191993d... |
@rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Agree! In retrospect, this was a rather ridiculous argument :sweat smile:. This however leaves us with only one justification for the change, and that is to bring the implementation in line with the documentation (see the Reference and Rustnomicon, which agree that
One complication is that even when removing the concept of Since this is more complicated than I initially believed, I think a T-types FCP may be necessary. |
One can argue against anything if one is so inclined :3 See this previous discussion: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/relating.20regions.20variance/near/284076240 For covariant regions to make sense the idea is to think of regions as a set of aliases. This is apparently how polonius models regions ^^ there the Not exactly sure what exactly is represented by the concept of an alias but I don't think we need an MCP for this as we've already had a previous discussion with signoff from niko, but we could open if you prefer ^^ |
mmm, I think we can ignore the FCP. |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (b5d497c598ccc0e78ce7392fced08b711191993d): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
✌️ @aliemjay can now approve this pull request |
@bors r+ |
@bors rollup |
💡 This pull request was already approved, no need to approve it again.
|
💡 This pull request was already approved, no need to approve it again.
|
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#107022 (Implement `SpecOptionPartialEq` for `cmp::Ordering`) - rust-lang#107100 (Use proper `InferCtxt` when probing for associated types in astconv) - rust-lang#107103 (Use new solver in `evaluate_obligation` query (when new solver is enabled)) - rust-lang#107190 (Recover from more const arguments that are not wrapped in curly braces) - rust-lang#107306 (Correct suggestions for closure arguments that need a borrow) - rust-lang#107339 (internally change regions to be covariant) - rust-lang#107344 (Minor tweaks in the new solver) - rust-lang#107373 (Don't merge vtables when full debuginfo is enabled.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Surprisingly, we consider the reference type
&'a T
to be contravaraint in its lifetime parameter. This is confusing and conflicts with the documentation we have in the reference, rustnomicon, and rustc-dev-guide. This also arguably not the correct use of terminology since we can use&'static u8
in a place where&' a u8
is expected, this implies that&'static u8 <: &' a u8
and consequently'static <: ' a
, hence covariance.Because of this, when relating two types, we used to switch the argument positions in a confusing way:
Subtype(&'a u8 <: &'b u8) => Subtype('b <: 'a) => Outlives('a: 'b) => RegionSubRegion('b <= 'a)
The reason for the current behavior is probably that we wanted
Subtype('b <: 'a)
andRegionSubRegion('b <= 'a)
to be equivalent, but I don' t think this is a good reason since these relations are sufficiently different in that the first is a relation in the subtyping lattice and is intrinsic to the type-systems, while the the second relation is an implementation detail of regionck.This PR changes this behavior to use covariance, so..
Subtype(&'a u8 <: &'b u8) => Subtype('a <: 'b) => Outlives('a: 'b) => RegionSubRegion('b <= 'a)
Resolves #103676
r? @lcnr