-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Move the AST from @T to Gc<T>, improve Gc<T> #14250
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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.