-
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
Allow hidden lifetimes in impl Trait
, take 2
#59402
Conversation
This comment has been minimized.
This comment has been minimized.
ef1bb1f
to
74a623f
Compare
This is a breaking change: trait X<'x>: Sized {}
impl<U> X<'_> for U {}
fn hide<'a, 'b, T: 'static>(x: &'a mut &'b T) -> impl X<'b> + 'a {
x
} |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
And this is still not sound: use std::cell::RefCell;
use std::rc::Rc;
trait Swap: Sized {
fn swap(self, other: Self);
}
impl<T> Swap for Rc<RefCell<T>> {
fn swap(self, other: Self) {
<RefCell<T>>::swap(&self, &other);
}
}
fn hide<'a, 'b: 'a, T: 'static>(x: Rc<RefCell<&'b T>>) -> impl Swap + 'a {
x
}
fn dangle() -> &'static [i32; 3] {
let long = Rc::new(RefCell::new(&[4, 5, 6]));
let x = [1, 2, 3];
let short = Rc::new(RefCell::new(&x));
hide(long.clone()).swap(hide(short));
let res: &'static [i32; 3] = *long.borrow();
res
}
fn main() {
println!("{:?}", dangle()); // prints nonsense values
} |
r? @nikomatsakis He wanted to look at this closely and it makes sense for him to approve. @matthewjasper's reviews and suggestions are of course appreciate too! |
@matthewjasper What do you think the new rule should be? Because I think we were all thinking the one used here should work... |
@nikomatsakis @matthewjasper commented to me in chat, "I don't think that there's a way to remove the restriction on the impl trait producer without adding one to the consumer." -- and I'm starting to think he's right. In his example, the line |
☔ The latest upstream changes (presumably #59632) made this pull request unmergeable. Please resolve the merge conflicts. |
Skipped on this week's T-Lang meeting since Niko wasn't here. Rescheduling for next week. |
We discussed this on Zulip some time ago. I think that the summary from that conversation was "it will be a non-trivial effort to figure out how to do this work soundly". I am going to close this PR because I don't think we're particularly close to doing that work (nor likely to have the bandwidth to do it in the near term). |
@nikomatsakis @Centril Fair enough about the postponement, but should we at least create a tracking issue for this, and link to this PR, #57870, and #56047 as prior attempts, so anyone tackling this in the future (maybe one of us) has all the info in one place, and others can follow it too? |
@alexreg That would be neat! If you can pack a good summary there it would be quite helpful. |
@Centril Is there a template for tracking issues? |
@alexreg They are typically made after RFCs but that doesn't apply so much here. That link is the one I know of for tracking issues. |
…rpit, r=aliemjay Add some unsoundness tests for opaques capturing hidden regions not in substs Commit tests from rust-lang#116040 (comment) and rust-lang#59402 (comment) so that we make sure not to regress them the next time that we relax the opaque capture rules :^)
Rollup merge of rust-lang#116730 - compiler-errors:unsoundness-tests-rpit, r=aliemjay Add some unsoundness tests for opaques capturing hidden regions not in substs Commit tests from rust-lang#116040 (comment) and rust-lang#59402 (comment) so that we make sure not to regress them the next time that we relax the opaque capture rules :^)
This is an attempt at reworking #57870, and operates with the principle that lifetimes (with respect to which the opaque type may be invariant) can only be hidden if they outlive the opaque type. This was discussed informally with @nikomatsakis before, and seems to have sound semantics, though it would be good to consider that again before merging. Certainly, although more conservative than the previous attempt (which can produce UB), it loosens the presently-standing rules whilst still preventing bad situations such as #57870 (comment).
r? @nikomatsakis
CC @cramertj @matthewjasper