-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Move the AST from @T to Gc<T>, improve Gc<T> #14250
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
Conversation
cc #14193 |
Note that this also purges all remnants of |
Wooo! |
@alexcrichton Some tests failed on Travis. |
Oops, forgot to push some changes, tests should be fixed now |
Reviving #13316 might be nice, although it's likely rebase-hell, given how large it is. |
Uh oh, this happened without mentioning me. It's sad how #13316 went stale without getting into any real decision making process. |
Travis is still sad |
@eddyb, this didn't take too much time, but I meant for this to be as small of a migration as possible. I didn't want to change the actual representation of the AST, I just wanted to remove all I would expect this to make further migrations a little easier because all the autoderef should have been taken care of (in order for this to bootstrap). Sadly, though, it still relies on the implicit copyability of |
Thanks @sfackler, should be addressed now |
@@ -73,8 +54,54 @@ impl<T> Clone for Gc<T> { | |||
#[cfg(not(test))] | |||
pub static GC: () = (); | |||
|
|||
#[cfg(test)] | |||
pub static GC: () = (); | |||
impl<T: Eq + 'static> Eq for Gc<T> { |
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.
These are buggy because they don't handle cycles, and Gc<T>
permits those in valid code.
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.
I'm not sure I follow. This is not a localized problem for Gc<T>
, it also affects Rc<T>
. Are you proposing we remove the trait implementations for both pointers, or just Gc<T>
?
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.
With Rc<T>
, it's a bug to create a strong reference cycle as it will leak. It's permitted in correct code for Gc<T>
though so it seems bad if ==
, etc. can stack overflow. I guess it could shove some metadata into a map in TLS to cope with it (not quite sure).
I'm okay with this as quick hack to remove |
This PR is meant as a step to removing the |
This commit uses the same trick as ~/Box to map Gc<T> to @t internally inside the compiler. This moves a number of implementations of traits to the `gc` module in the standard library. This removes functions such as `Gc::new`, `Gc::borrow`, and `Gc::ptr_eq` in favor of the more modern equivalents, `box(GC)`, `Deref`, and pointer equality. The Gc pointer itself should be much more useful now, and subsequent commits will move the compiler away from @t towards Gc<T> [breaking-change]
This commit removes `@T` from the compiler by moving the AST to using `Gc<T>`. This also starts treating `Gc<T>` as `@T` in the same way that `Box<T>` is the same as `~T` in the compiler. After this hits a snapshot, the `@T` syntax should be able to be removed completely.
This commit removes
@T
from the compiler by moving the AST to usingGc<T>
. This also starts treatingGc<T>
as@T
in the same way thatBox<T>
is the same as~T
in the compiler.After this hits a snapshot, the
@T
syntax should be able to be removed completely.