Invalid Rc/RefCell borrow when having a Gc pointer inside #11532
Comments
|
This is almost certainly because |
|
This just plain segfaults: fn main() {
use std::{cell,gc,rc};
let a = rc::Rc::new(cell::RefCell::new( gc::Gc::new(1) ));
let x = a.borrow();
println!("{:?}", x);
let y = x.try_borrow_mut();
println!("{:?}", y);
assert!(y.is_some());
}backtrace: |
|
(from this we can infer that a pointer somewhere is null. more likely, some data somewhere is of the wrong representation) |
|
Supporting this isn't planned. This is part of replacing managed pointers with a real garbage collector. We were aware of the issue when the pull request for the new implementation of |
|
#10926 (comment) (most of the discussion was on IRC) |
|
There's no way that we're releasing 1.0 without a better story here. |
|
This will be fixed with a GC like the one in #11399; although that may not land, and other designs could have this problem. |
|
@alexcrichton: 1.0 isn't going to be released with these old managed pointers. This issue is not actionable because we agreed that adding complexity to support a feature that's on the way out makes no sense. There's no point in leaving an issue open if a pull request fixing it wouldn't be merged. #2997 supersedes this issue. |
|
Did we ship 0.9 with that bug in? The elephant in the room here is not that managed pointers are not supported inside Rc, but the fact that one can waste multiple hours figuring out what's wrong should he happen to upgrade his code base from "@mut" to Gc/Rc. In fact, that's what happened to me, and nowhere did I notice a big fat warning that no Gc/'@' are allowed inside Rc, not even in This Week in Rust. There is no need to fix this, instead it would help to just put a proper compiler error/warning on that case until it gets properly resolved with the new Gc. |
|
@kvark: This issue has been present long before 0.9. If you look at the pull request, you'll see that I originally added a This trait is not going to be necessary once the garbage collector is implemented, so #2997 is the real issue. We can stick an |
|
@thestinger Thanks for the explanation. I doubt marking Gc experimental is a good idea, because using Gc inside of Gc seems to work fine. Instead, marking Rc as experimental would provide a better protection. Meanwhile, using Gc instead of Rc is a temporary workaround, at least for me. |
|
The There's not currently a reason to use it over |
The code in Rc assumes that the inner box is allocated on the global exchange heap, which is not always true. If T has managed pointers inside of it, it's allocate on the local heap instead. This commit reconciles these two modes of T by carefully interacting with the inner box (with special treatment of its deallocation). Closes rust-lang#11532
|
We could migrate |
|
@huonw: Is |
|
Yes, as |
|
It would be a good idea to mark it with something like The subset of cases where the cycles are non-owning are handled by |
|
Closed by #11535 |
…nment, r=flodiebold feat: implement destructuring assignment This is an attempt to implement destructuring assignments, or more specifically, type inference for [assignee expressions](https://doc.rust-lang.org/reference/expressions.html#place-expressions-and-value-expressions). I'm not sure if this is the right approach, so I don't even expect this to be merged (hence the branch name 😉) but rather want to propose one direction we could choose. I don't mind getting merged if this is good enough though! Some notes on the implementation choices: - Assignee expressions are **not** desugared on HIR level unlike rustc, but are inferred directly along with other expressions. This matches the processing of other syntaxes that are desugared in rustc but not in r-a. I find this reasonable because r-a only needs to infer types and it's easier to relate AST nodes and HIR nodes, so I followed it. - Assignee expressions obviously resemble patterns, so type inference for each kind of pattern and its corresponding assignee expressions share a significant amount of logic. I tried to reuse the type inference functions for patterns by introducing `PatLike` trait which generalizes assignee expressions and patterns. - This is not the most elegant solution I suspect (and I really don't like the name of the trait!), but it's cleaner and the change is smaller than other ways I experimented, like making the functions generic without such trait, or making them take `Either<ExprId, PatId>` in place of `PatId`. in case this is merged: Closes rust-lang#11532 Closes rust-lang#11839 Closes rust-lang#12322
Expected output = none.
Actual output:
The text was updated successfully, but these errors were encountered: