From 5c5cca58f7c8e59703892d9500327aafdd44e45e Mon Sep 17 00:00:00 2001 From: Jack Wilson Date: Sun, 6 Sep 2015 16:23:44 -0700 Subject: [PATCH 01/11] Small syntax and formatting changes --- src/doc/trpl/guessing-game.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/doc/trpl/guessing-game.md b/src/doc/trpl/guessing-game.md index 4a35022b03c..3a4328562f8 100644 --- a/src/doc/trpl/guessing-game.md +++ b/src/doc/trpl/guessing-game.md @@ -599,7 +599,7 @@ With this definition, anything of type `Foo` can be either a `Foo::Bar` or a `Foo::Baz`. We use the `::` to indicate the namespace for a particular `enum` variant. -The [`Ordering`][ordering] enum has three possible variants: `Less`, `Equal`, +The [`Ordering`][ordering] `enum` has three possible variants: `Less`, `Equal`, and `Greater`. The `match` statement takes a value of a type, and lets you create an ‘arm’ for each possible value. Since we have three types of `Ordering`, we have three arms: @@ -918,9 +918,9 @@ let guess: u32 = match guess.trim().parse() { This is how you generally move from ‘crash on error’ to ‘actually handle the error’, by switching from `ok().expect()` to a `match` statement. The `Result` -returned by `parse()` is an enum just like `Ordering`, but in this case, each +returned by `parse()` is an `enum` just like `Ordering`, but in this case, each variant has some data associated with it: `Ok` is a success, and `Err` is a -failure. Each contains more information: the successful parsed integer, or an +failure. Each contains more information: the successfully parsed integer, or an error type. In this case, we `match` on `Ok(num)`, which sets the inner value of the `Ok` to the name `num`, and then we just return it on the right-hand side. In the `Err` case, we don’t care what kind of error it is, so we just From 320880eed5e960f6107cfbe039a5eba33f209f32 Mon Sep 17 00:00:00 2001 From: christopherdumas Date: Tue, 15 Sep 2015 07:54:43 -0700 Subject: [PATCH 02/11] Fix option link and anchor links. --- src/doc/trpl/error-handling.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/doc/trpl/error-handling.md b/src/doc/trpl/error-handling.md index 673dc950ecc..2b590c82a89 100644 --- a/src/doc/trpl/error-handling.md +++ b/src/doc/trpl/error-handling.md @@ -33,12 +33,12 @@ systems may want to jump around. * [Composing `Option` and `Result`](#composing-option-and-result) * [The limits of combinators](#the-limits-of-combinators) * [Early returns](#early-returns) - * [The `try!` macro](#the-try-macro) + * [The `try!` macro](#the-try!-macro) * [Defining your own error type](#defining-your-own-error-type) * [Standard library traits used for error handling](#standard-library-traits-used-for-error-handling) * [The `Error` trait](#the-error-trait) * [The `From` trait](#the-from-trait) - * [The real `try!` macro](#the-real-try-macro) + * [The real `try!` macro](#the-real-try!-macro) * [Composing custom error types](#composing-custom-error-types) * [Advice for library writers](#advice-for-library-writers) * [Case study: A program to read population data](#case-study-a-program-to-read-population-data) @@ -120,10 +120,9 @@ It would be better if we just showed the code for unwrapping because it is so simple, but to do that, we will first need to explore the `Option` and `Result` types. Both of these types have a method called `unwrap` defined on them. -## The `Option` type +### The `Option` type -The `Option` type is -[defined in the standard library][1]: +The `Option` type is [defined in the standard library][5]: ```rust enum Option { From b69a51164d078b00d97a4aa7d4a91ec3f4f5a074 Mon Sep 17 00:00:00 2001 From: christopherdumas Date: Tue, 15 Sep 2015 10:31:48 -0700 Subject: [PATCH 03/11] Added anchors for the code snippets. --- src/doc/trpl/error-handling.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/doc/trpl/error-handling.md b/src/doc/trpl/error-handling.md index 2b590c82a89..0687c2b13b5 100644 --- a/src/doc/trpl/error-handling.md +++ b/src/doc/trpl/error-handling.md @@ -87,7 +87,9 @@ thread '
' panicked at 'Invalid number: 11', src/bin/panic-simple.rs:5 Here's another example that is slightly less contrived. A program that accepts an integer as an argument, doubles it and prints it. + ```rust,should_panic + use std::env; fn main() { @@ -137,6 +139,7 @@ system is an important concept because it will cause the compiler to force the programmer to handle that absence. Let's take a look at an example that tries to find a character in a string: + ```rust // Searches `haystack` for the Unicode character `needle`. If one is found, the // byte offset of the character is returned. Otherwise, `None` is returned. From 1b3745fe145a18df44156f24c5c31ca9bf26883d Mon Sep 17 00:00:00 2001 From: Tobias Bucher Date: Wed, 9 Sep 2015 12:12:25 +0100 Subject: [PATCH 04/11] Add a comment that the `Atomic*` are all implicitly `Send` --- src/libcore/sync/atomic.rs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/libcore/sync/atomic.rs b/src/libcore/sync/atomic.rs index 53952cdc908..0f72dcc1281 100644 --- a/src/libcore/sync/atomic.rs +++ b/src/libcore/sync/atomic.rs @@ -92,6 +92,7 @@ impl Default for AtomicBool { } } +// Send is implicitly implemented for AtomicBool. unsafe impl Sync for AtomicBool {} /// A signed integer type which can be safely shared between threads. @@ -106,6 +107,7 @@ impl Default for AtomicIsize { } } +// Send is implicitly implemented for AtomicIsize. unsafe impl Sync for AtomicIsize {} /// An unsigned integer type which can be safely shared between threads. @@ -120,6 +122,7 @@ impl Default for AtomicUsize { } } +// Send is implicitly implemented for AtomicUsize. unsafe impl Sync for AtomicUsize {} /// A raw pointer type which can be safely shared between threads. From 9a626df476119b79f8ebfa7d92f4a82ac9ef893e Mon Sep 17 00:00:00 2001 From: Andrew Paseltiner Date: Wed, 16 Sep 2015 06:50:24 -0400 Subject: [PATCH 05/11] Add test for #24533 Closes #24533. --- src/test/run-pass/issue-24533.rs | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 src/test/run-pass/issue-24533.rs diff --git a/src/test/run-pass/issue-24533.rs b/src/test/run-pass/issue-24533.rs new file mode 100644 index 00000000000..440a4184780 --- /dev/null +++ b/src/test/run-pass/issue-24533.rs @@ -0,0 +1,32 @@ +// Copyright 2015 The Rust Project Developers. See the COPYRIGHT +// file at the top-level directory of this distribution and at +// http://rust-lang.org/COPYRIGHT. +// +// Licensed under the Apache License, Version 2.0 or the MIT license +// , at your +// option. This file may not be copied, modified, or distributed +// except according to those terms. + +use std::slice::Iter; +use std::io::{Error, ErrorKind, Result}; +use std::vec::*; + +fn foo(it: &mut Iter) -> Result { + Ok(*it.next().unwrap()) +} + +fn bar() -> Result { + let data: Vec = Vec::new(); + + if true { + return Err(Error::new(ErrorKind::NotFound, "msg")); + } + + let mut it = data.iter(); + foo(&mut it) +} + +fn main() { + bar(); +} From dfe88c09b86c47dad3e4758469beff409ae8533a Mon Sep 17 00:00:00 2001 From: Dongie Agnir Date: Wed, 16 Sep 2015 18:56:56 -0400 Subject: [PATCH 06/11] Change OSX version req wording to match Linux. --- src/doc/trpl/installing-rust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/trpl/installing-rust.md b/src/doc/trpl/installing-rust.md index f06005d55b9..366069ac9a3 100644 --- a/src/doc/trpl/installing-rust.md +++ b/src/doc/trpl/installing-rust.md @@ -64,7 +64,7 @@ Oh, we should also mention the officially supported platforms: * Windows (7, 8, Server 2008 R2) * Linux (2.6.18 or later, various distributions), x86 and x86-64 -* OSX 10.7 (Lion) or greater, x86 and x86-64 +* OSX 10.7 (Lion) or later, x86 and x86-64 We extensively test Rust on these platforms, and a few others, too, like Android. But these are the ones most likely to work, as they have the most From 6d2cb6c688ce0a8aa309236dd04b45149f8eee3c Mon Sep 17 00:00:00 2001 From: Bastien Dejean Date: Thu, 17 Sep 2015 18:53:01 +0200 Subject: [PATCH 07/11] trpl: Fix off-by-one highest memory address --- src/doc/trpl/the-stack-and-the-heap.md | 168 ++++++++++++------------- 1 file changed, 84 insertions(+), 84 deletions(-) diff --git a/src/doc/trpl/the-stack-and-the-heap.md b/src/doc/trpl/the-stack-and-the-heap.md index fb778b59a3d..aca736ef2ac 100644 --- a/src/doc/trpl/the-stack-and-the-heap.md +++ b/src/doc/trpl/the-stack-and-the-heap.md @@ -217,18 +217,18 @@ on the heap. The actual value of the box is a structure which has a pointer to it allocates some memory for the heap, and puts `5` there. The memory now looks like this: -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 5 | -| ... | ... | ... | -| 1 | y | 42 | -| 0 | x | → 230 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 5 | +| ... | ... | ... | +| 1 | y | 42 | +| 0 | x | → (230) - 1 | -We have 230 in our hypothetical computer with 1GB of RAM. And since +We have (230) - 1 in our hypothetical computer with 1GB of RAM. And since our stack grows from zero, the easiest place to allocate memory is from the other end. So our first value is at the highest place in memory. And the value of the struct at `x` has a [raw pointer][rawpointer] to the place we’ve -allocated on the heap, so the value of `x` is 230, the memory +allocated on the heap, so the value of `x` is (230) - 1, the memory location we’ve asked for. [rawpointer]: raw-pointers.html @@ -244,18 +244,18 @@ layout of a program which has been running for a while now: | Address | Name | Value | |----------------------|------|------------------------| -| 230 | | 5 | -| (230) - 1 | | | +| (230) - 1 | | 5 | | (230) - 2 | | | -| (230) - 3 | | 42 | +| (230) - 3 | | | +| (230) - 4 | | 42 | | ... | ... | ... | -| 3 | y | → (230) - 3 | +| 3 | y | → (230) - 4 | | 2 | y | 42 | | 1 | y | 42 | -| 0 | x | → 230 | +| 0 | x | → (230) - 1 | In this case, we’ve allocated four things on the heap, but deallocated two of -them. There’s a gap between 230 and (230) - 3 which isn’t +them. There’s a gap between (230) - 1 and (230) - 4 which isn’t currently being used. The specific details of how and why this happens depends on what kind of strategy you use to manage the heap. Different programs can use different ‘memory allocators’, which are libraries that manage this for you. @@ -366,29 +366,29 @@ fn main() { First, we call `main()`: -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 20 | -| ... | ... | ... | -| 2 | j | → 0 | -| 1 | i | → 230 | -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | We allocate memory for `j`, `i`, and `h`. `i` is on the heap, and so has a value pointing there. Next, at the end of `main()`, `foo()` gets called: -| Address | Name | Value | -|-----------------|------|-----------------| -| 230 | | 20 | -| ... | ... | ... | -| 5 | z | → 4 | -| 4 | y | 10 | -| 3 | x | → 0 | -| 2 | j | → 0 | -| 1 | i | → 230| -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 5 | z | → 4 | +| 4 | y | 10 | +| 3 | x | → 0 | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | Space gets allocated for `x`, `y`, and `z`. The argument `x` has the same value as `j`, since that’s what we passed it in. It’s a pointer to the `0` address, @@ -396,42 +396,42 @@ since `j` points at `h`. Next, `foo()` calls `baz()`, passing `z`: -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 20 | -| ... | ... | ... | -| 7 | g | 100 | -| 6 | f | → 4 | -| 5 | z | → 4 | -| 4 | y | 10 | -| 3 | x | → 0 | -| 2 | j | → 0 | -| 1 | i | → 230 | -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 7 | g | 100 | +| 6 | f | → 4 | +| 5 | z | → 4 | +| 4 | y | 10 | +| 3 | x | → 0 | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | We’ve allocated memory for `f` and `g`. `baz()` is very short, so when it’s over, we get rid of its stack frame: -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 20 | -| ... | ... | ... | -| 5 | z | → 4 | -| 4 | y | 10 | -| 3 | x | → 0 | -| 2 | j | → 0 | -| 1 | i | → 230 | -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 5 | z | → 4 | +| 4 | y | 10 | +| 3 | x | → 0 | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | Next, `foo()` calls `bar()` with `x` and `z`: | Address | Name | Value | |----------------------|------|------------------------| -| 230 | | 20 | -| (230) - 1 | | 5 | +| (230) - 1 | | 20 | +| (230) - 2 | | 5 | | ... | ... | ... | | 10 | e | → 9 | -| 9 | d | → (230) - 1 | +| 9 | d | → (230) - 2 | | 8 | c | 5 | | 7 | b | → 4 | | 6 | a | → 0 | @@ -439,24 +439,24 @@ Next, `foo()` calls `bar()` with `x` and `z`: | 4 | y | 10 | | 3 | x | → 0 | | 2 | j | → 0 | -| 1 | i | → 230 | +| 1 | i | → (230) - 1 | | 0 | h | 3 | We end up allocating another value on the heap, and so we have to subtract one -from 230. It’s easier to just write that than `1,073,741,823`. In any +from (230) - 1. It’s easier to just write that than `1,073,741,822`. In any case, we set up the variables as usual. At the end of `bar()`, it calls `baz()`: | Address | Name | Value | |----------------------|------|------------------------| -| 230 | | 20 | -| (230) - 1 | | 5 | +| (230) - 1 | | 20 | +| (230) - 2 | | 5 | | ... | ... | ... | | 12 | g | 100 | | 11 | f | → 9 | | 10 | e | → 9 | -| 9 | d | → (230) - 1 | +| 9 | d | → (230) - 2 | | 8 | c | 5 | | 7 | b | → 4 | | 6 | a | → 0 | @@ -464,7 +464,7 @@ At the end of `bar()`, it calls `baz()`: | 4 | y | 10 | | 3 | x | → 0 | | 2 | j | → 0 | -| 1 | i | → 230 | +| 1 | i | → (230) - 1 | | 0 | h | 3 | With this, we’re at our deepest point! Whew! Congrats for following along this @@ -474,11 +474,11 @@ After `baz()` is over, we get rid of `f` and `g`: | Address | Name | Value | |----------------------|------|------------------------| -| 230 | | 20 | -| (230) - 1 | | 5 | +| (230) - 1 | | 20 | +| (230) - 2 | | 5 | | ... | ... | ... | | 10 | e | → 9 | -| 9 | d | → (230) - 1 | +| 9 | d | → (230) - 2 | | 8 | c | 5 | | 7 | b | → 4 | | 6 | a | → 0 | @@ -486,32 +486,32 @@ After `baz()` is over, we get rid of `f` and `g`: | 4 | y | 10 | | 3 | x | → 0 | | 2 | j | → 0 | -| 1 | i | → 230 | +| 1 | i | → (230) - 1 | | 0 | h | 3 | Next, we return from `bar()`. `d` in this case is a `Box`, so it also frees -what it points to: (230) - 1. +what it points to: (230) - 2. -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 20 | -| ... | ... | ... | -| 5 | z | → 4 | -| 4 | y | 10 | -| 3 | x | → 0 | -| 2 | j | → 0 | -| 1 | i | → 230 | -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 5 | z | → 4 | +| 4 | y | 10 | +| 3 | x | → 0 | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | And after that, `foo()` returns: -| Address | Name | Value | -|-----------------|------|------------------| -| 230 | | 20 | -| ... | ... | ... | -| 2 | j | → 0 | -| 1 | i | → 230 | -| 0 | h | 3 | +| Address | Name | Value | +|----------------------|------|------------------------| +| (230) - 1 | | 20 | +| ... | ... | ... | +| 2 | j | → 0 | +| 1 | i | → (230) - 1 | +| 0 | h | 3 | And then, finally, `main()`, which cleans the rest up. When `i` is `Drop`ped, it will clean up the last of the heap too. From 25cc001c194ac9a1134a30a99ad721695c3c0e8c Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Sep 2015 21:46:46 +0200 Subject: [PATCH 08/11] doc: no need to mention the method by name It's clear it's the one being documented --- src/libcore/ops.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libcore/ops.rs b/src/libcore/ops.rs index 07de4d0761b..5f0eb63edbc 100644 --- a/src/libcore/ops.rs +++ b/src/libcore/ops.rs @@ -94,7 +94,7 @@ use fmt; #[lang = "drop"] #[stable(feature = "rust1", since = "1.0.0")] pub trait Drop { - /// The `drop` method, called when the value goes out of scope. + /// A method called when the value goes out of scope. #[stable(feature = "rust1", since = "1.0.0")] fn drop(&mut self); } From 553a2f1ead6e6c9be8b6d3b0a556a26141206715 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Sep 2015 22:13:05 +0200 Subject: [PATCH 09/11] doc: follow idiom in code snippet --- src/doc/reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/reference.md b/src/doc/reference.md index 717c99901d1..efb986e19ed 100644 --- a/src/doc/reference.md +++ b/src/doc/reference.md @@ -2762,7 +2762,7 @@ The following expressions are equivalent. let x = std::ops::Range {start: 0, end: 10}; let y = 0..10; -assert_eq!(x,y); +assert_eq!(x, y); ``` ### Unary operator expressions From 22fc5f480d5ec3caf1e6e7cd4192c946d488ff2a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Sep 2015 22:52:39 +0200 Subject: [PATCH 10/11] reference: mark that up to make it more clear it is a keyword --- src/doc/reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/doc/reference.md b/src/doc/reference.md index 717c99901d1..6035f936c6c 100644 --- a/src/doc/reference.md +++ b/src/doc/reference.md @@ -3087,7 +3087,7 @@ loops](#infinite-loops), [break expressions](#break-expressions), and A `for` expression is a syntactic construct for looping over elements provided by an implementation of `std::iter::IntoIterator`. -An example of a for loop over the contents of an array: +An example of a `for` loop over the contents of an array: ``` # type Foo = i32; From a3305f87c154aae5e7b46f4525683567a0938455 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Sep 2015 22:24:15 +0200 Subject: [PATCH 11/11] reference: actual keywords feel more appropriate --- src/doc/reference.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/doc/reference.md b/src/doc/reference.md index 717c99901d1..d7d9f938ed8 100644 --- a/src/doc/reference.md +++ b/src/doc/reference.md @@ -3035,10 +3035,10 @@ A `loop` expression may optionally have a _label_. The label is written as a lifetime preceding the loop expression, as in `'foo: loop{ }`. If a label is present, then labeled `break` and `continue` expressions nested within this loop may exit out of this loop or return control to its head. -See [Break expressions](#break-expressions) and [Continue +See [break expressions](#break-expressions) and [continue expressions](#continue-expressions). -### Break expressions +### `break` expressions A `break` expression has an optional _label_. If the label is absent, then executing a `break` expression immediately terminates the innermost loop @@ -3046,7 +3046,7 @@ enclosing it. It is only permitted in the body of a loop. If the label is present, then `break 'foo` terminates the loop with label `'foo`, which need not be the innermost label enclosing the `break` expression, but must enclose it. -### Continue expressions +### `continue` expressions A `continue` expression has an optional _label_. If the label is absent, then executing a `continue` expression immediately terminates the current iteration @@ -3059,7 +3059,7 @@ innermost label enclosing the `break` expression, but must enclose it. A `continue` expression is only permitted in the body of a loop. -### While loops +### `while` loops A `while` loop begins by evaluating the boolean loop conditional expression. If the loop conditional expression evaluates to `true`, the loop body block @@ -3082,7 +3082,7 @@ Like `loop` expressions, `while` loops can be controlled with `break` or loops](#infinite-loops), [break expressions](#break-expressions), and [continue expressions](#continue-expressions) for more information. -### For expressions +### `for` expressions A `for` expression is a syntactic construct for looping over elements provided by an implementation of `std::iter::IntoIterator`. @@ -3117,7 +3117,7 @@ Like `loop` expressions, `for` loops can be controlled with `break` or loops](#infinite-loops), [break expressions](#break-expressions), and [continue expressions](#continue-expressions) for more information. -### If expressions +### `if` expressions An `if` expression is a conditional branch in program control. The form of an `if` expression is a condition expression, followed by a consequent block, any @@ -3129,7 +3129,7 @@ evaluates to `false`, the consequent block is skipped and any subsequent `else if` condition is evaluated. If all `if` and `else if` conditions evaluate to `false` then any `else` block is executed. -### Match expressions +### `match` expressions A `match` expression branches on a *pattern*. The exact form of matching that occurs depends on the pattern. Patterns consist of some combination of @@ -3235,7 +3235,7 @@ let message = match maybe_digit { }; ``` -### If let expressions +### `if let` expressions An `if let` expression is semantically identical to an `if` expression but in place of a condition expression it expects a refutable let statement. If the value of the @@ -3256,7 +3256,7 @@ if let ("Ham", b) = dish { } ``` -### While let loops +### `while let` loops A `while let` loop is semantically identical to a `while` loop but in place of a condition expression it expects a refutable let statement. If the value of the @@ -3264,7 +3264,7 @@ expression on the right hand side of the let statement matches the pattern, the loop body block executes and control returns to the pattern matching statement. Otherwise, the while expression completes. -### Return expressions +### `return` expressions Return expressions are denoted with the keyword `return`. Evaluating a `return` expression moves its argument into the designated output location for the