Skip to content
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

Merged
merged 1 commit into from
Jan 10, 2014

Conversation

pcwalton
Copy link
Contributor

@@ -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),
Copy link
Member

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?

Copy link
Contributor Author

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.

@brson
Copy link
Contributor

brson commented Dec 18, 2013

Exciting!

///
/// Use this like `let foo = box(GC) Bar::new(...);`
#[lang="managed_heap"]
pub static GC: () = ();
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

@nikomatsakis
Copy link
Contributor

r+ --- looks good to me.

  • Can you add a compile-fail test for the error case? (before landing)
  • Also we should bikeshed the name of HEAP/GC (I guess this can land independently)

@@ -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.
Copy link
Contributor

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

@emberian
Copy link
Member

(also needs a rebase)

@brson
Copy link
Contributor

brson commented Jan 9, 2014

Agree we should keep discussing the names HEAP/GC.

@bors bors closed this Jan 10, 2014
@bors bors merged commit e127115 into rust-lang:master Jan 10, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jul 14, 2023
"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").
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants