-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
librustc: Implement placement box
for GC and unique pointers.
#11055
Conversation
@@ -547,6 +547,8 @@ pub enum CallSugar { | |||
#[deriving(Clone, Eq, Encodable, Decodable, IterBytes)] | |||
pub enum Expr_ { | |||
ExprVstore(@Expr, ExprVstore), | |||
// First expr is the place; second expr is the value. | |||
ExprBox(@Expr, @Expr), |
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.
Should the first expression be optional to allow for a better pretty-printing experience?
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.
Yes, eventually, but right now the non-optional one is parsed the same as ExprUnary
for backwards compat.
Exciting! |
/// | ||
/// Use this like `let foo = box(GC) Bar::new(...);` | ||
#[lang="managed_heap"] | ||
pub static GC: () = (); |
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.
Shouldn't we call this Gc
to match the type name? I don't really care which convention we use, but I guess we ought to be consistent.
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.
Agree this should be Gc.
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.
Oh, it's a static, and all caps is the convention.
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.
On Thu, Jan 09, 2014 at 11:38:28AM -0800, Brian Anderson wrote:
+pub static GC: () = ();
Oh, it's a static, and all caps is the convention.
Just to put some thoughts out there before I forget:
All caps is the convention for constants, but I don't consider Gc
or
Heap
to be constants, even though they are static values. The
capitalization of static values already varies quite a bit depending
on what kind of static value it is. For example, when one writes:
struct Foo(uint);
one is also declaring a static value, but we don't make the name of
"Foo
the type" and "Foo
the constructor function" distinct.
Similarly, fn foo() { ... }
declares a static value, and yet we
don't write fn FOO() {}
. Therefore, I don't see the harm in saying:
static values that are intended to serve as allocators should be named
differently from constants like BUFFER_LENGTH
.
r+ --- looks good to me.
|
@@ -12,6 +12,16 @@ | |||
|
|||
#[cfg(not(test))] use cmp::*; | |||
|
|||
/// A value that represents the global exchange heap. This is the default | |||
/// place that the `box` keyword allocates into no place is supplied. |
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.
Typo: allocates into no place
-> allocates into when no place
(also needs a rebase) |
Agree we should keep discussing the names HEAP/GC. |
"try this" -> "try" Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of rust-lang#10631, this PR adopts the first, as it is the most concise. It also updates the `lint_message_conventions` test to catch cases of "try this". (Aside: rust-lang#10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.) changelog: Make help messages more concise ("try this" -> "try").
r? @nikomatsakis