Rollup of 34 pull requests

mk/docs.mk

@@ -27,7 +27,7 @@
 ######################################################################
 DOCS := index intro tutorial complement-bugreport \
     complement-lang-faq complement-design-faq complement-project-faq \
-    rustdoc reference
+    rustdoc reference grammar
 
 # Legacy guides, preserved for a while to reduce the number of 404s
 DOCS += guide-crates guide-error-handling guide-ffi guide-macros guide \

mk/main.mk

@@ -61,13 +61,16 @@ SPACE :=
 SPACE +=
 ifneq ($(CFG_GIT),)
 ifneq ($(wildcard $(subst $(SPACE),\$(SPACE),$(CFG_GIT_DIR))),)
-    CFG_VER_DATE = $(shell git --git-dir='$(CFG_GIT_DIR)' log -1 --pretty=format:'%ci')
+    CFG_VER_DATE = $(shell git --git-dir='$(CFG_GIT_DIR)' log -1 --date=short --pretty=format:'%cd')
     CFG_VER_HASH = $(shell git --git-dir='$(CFG_GIT_DIR)' rev-parse HEAD)
     CFG_SHORT_VER_HASH = $(shell git --git-dir='$(CFG_GIT_DIR)' rev-parse --short=9 HEAD)
     CFG_VERSION += ($(CFG_SHORT_VER_HASH) $(CFG_VER_DATE))
 endif
 endif
 
+CFG_BUILD_DATE = $(shell date +%F)
+CFG_VERSION += (built $(CFG_BUILD_DATE))
+
 # Windows exe's need numeric versions - don't use anything but
 # numbers and dots here
 CFG_VERSION_WIN = $(CFG_RELEASE_NUM)
@@ -317,6 +320,7 @@ endif
 ifdef CFG_VER_HASH
 export CFG_VER_HASH
 endif
+export CFG_BUILD_DATE
 export CFG_VERSION
 export CFG_VERSION_WIN
 export CFG_RELEASE

src/compiletest/compiletest.rs

@@ -16,7 +16,7 @@
 #![feature(io)]
 #![feature(path)]
 #![feature(rustc_private)]
-#![feature(slicing_syntax, unboxed_closures)]
+#![feature(unboxed_closures)]
 #![feature(std_misc)]
 #![feature(test)]
 #![feature(unicode)]

src/doc/complement-bugreport.md

@@ -56,8 +56,6 @@ $ RUST_BACKTRACE=1 rustc ...
 
 # I submitted a bug, but nobody has commented on it!
 
-This is sad, but does happen sometimes, since we're short-staffed. If you
-submit a bug and you haven't received a comment on it within 3 business days,
-it's entirely reasonable to either ask on the #rust IRC channel,
-or post on the [rust-dev mailing list](https://mail.mozilla.org/listinfo/rust-dev)
-to ask what the status of the bug is.
+This is sad, but does happen sometimes, since we're short-staffed. If you submit a
+bug and you haven't received a comment on it within 3 business days, it's entirely
+reasonable to ask about the status of the bug in #rust on irc.mozilla.org.

src/doc/grammar.md

@@ -1,6 +1,4 @@
-# **This is a work in progress**
-
-% The Rust Grammar
+% Grammar
 
 # Introduction
 

src/doc/intro.md

@@ -224,7 +224,7 @@ segfault when we allocate more memory?
 
 The answer is that in the C++ version, `x` is a *reference* to the memory
 location where the first element of the array is stored. But in Ruby, `x` is a
-standalone value, not connected to the underyling array at all. Let's dig into
+standalone value, not connected to the underlying array at all. Let's dig into
 the details for a moment. Your program has access to memory, provided to it by
 the operating system. Each location in memory has an address.  So when we make
 our vector, `v`, it's stored in a memory location somewhere:

src/doc/reference.md

@@ -5,9 +5,7 @@
 This document is the primary reference for the Rust programming language. It
 provides three kinds of material:
 
-  - Chapters that formally define the language grammar and, for each
-    construct, informally describe its semantics and give examples of its
-    use.
+  - Chapters that informally describe each language construct and their use.
   - Chapters that informally describe the memory model, concurrency model,
     runtime services, linkage model and debugging facilities.
   - Appendix chapters providing rationale and references to languages that
@@ -23,8 +21,11 @@ separately by extracting documentation attributes from their source code. Many
 of the features that one might expect to be language features are library
 features in Rust, so what you're looking for may be there, not here.
 
+You may also be interested in the [grammar].
+
 [book]: book/index.html
 [standard]: std/index.html
+[grammar]: grammar.html
 
 # Notation
 
@@ -2377,21 +2378,33 @@ considered off, and using the features will result in a compiler error.
 
 The currently implemented features of the reference compiler are:
 
+* `advanced_slice_patterns` - see the [match expressions](#match-expressions)
+                              section for discussion; the exact semantics of
+                              slice patterns are subject to change.
+
 * `asm` - The `asm!` macro provides a means for inline assembly. This is often
           useful, but the exact syntax for this feature along with its
           semantics are likely to change, so this macro usage must be opted
           into.
 
+* `associated_types` - Allows type aliases in traits. Experimental.
+
+* `box_patterns` - Allows `box` patterns, the exact semantics of which
+                   is subject to change.
+
+* `box_syntax` - Allows use of `box` expressions, the exact semantics of which
+                 is subject to change.
+
 * `concat_idents` - Allows use of the `concat_idents` macro, which is in many
                     ways insufficient for concatenating identifiers, and may be
                     removed entirely for something more wholesome.
 
-* `default_type_params` - Allows use of default type parameters. The future of
-                          this feature is uncertain.
-
 * `intrinsics` - Allows use of the "rust-intrinsics" ABI. Compiler intrinsics
                  are inherently unstable and no promise about them is made.
 
+* `int_uint` - Allows the use of the `int` and `uint` types, which are deprecated.
+               Use `isize` and `usize` instead.
+
 * `lang_items` - Allows use of the `#[lang]` attribute. Like `intrinsics`,
                  lang items are inherently unstable and no promise about them
                  is made.
@@ -2410,12 +2423,33 @@ The currently implemented features of the reference compiler are:
 * `log_syntax` - Allows use of the `log_syntax` macro attribute, which is a
                  nasty hack that will certainly be removed.
 
+* `main` - Allows use of the `#[main]` attribute, which changes the entry point
+           into a Rust program. This capabiilty is subject to change.
+
+* `macro_reexport` - Allows macros to be re-exported from one crate after being imported
+                     from another. This feature was originally designed with the sole
+                     use case of the Rust standard library in mind, and is subject to
+                     change.
+
 * `non_ascii_idents` - The compiler supports the use of non-ascii identifiers,
                        but the implementation is a little rough around the
                        edges, so this can be seen as an experimental feature
                        for now until the specification of identifiers is fully
                        fleshed out.
 
+* `no_std` - Allows the `#![no_std]` crate attribute, which disables the implicit
+             `extern crate std`. This typically requires use of the unstable APIs
+             behind the libstd "facade", such as libcore and libcollections. It
+             may also cause problems when using syntax extensions, including
+             `#[derive]`.
+
+* `on_unimplemented` - Allows the `#[rustc_on_unimplemented]` attribute, which allows
+                       trait definitions to add specialized notes to error messages
+                       when an implementation was expected but not found.
+
+* `optin_builtin_traits` - Allows the definition of default and negative trait
+                           implementations. Experimental.
+
 * `plugin` - Usage of [compiler plugins][plugin] for custom lints or syntax extensions.
              These depend on compiler internals and are subject to change.
 
@@ -2431,8 +2465,15 @@ The currently implemented features of the reference compiler are:
 * `simd` - Allows use of the `#[simd]` attribute, which is overly simple and
            not the SIMD interface we want to expose in the long term.
 
+* `simd_ffi` - Allows use of SIMD vectors in signatures for foreign functions.
+               The SIMD interface is subject to change.
+
 * `staged_api` - Allows usage of stability markers and `#![staged_api]` in a crate
 
+* `start` - Allows use of the `#[start]` attribute, which changes the entry point
+            into a Rust program. This capabiilty, especially the signature for the
+            annotated function, is subject to change.
+
 * `struct_inherit` - Allows using struct inheritance, which is barely
                      implemented and will probably be removed. Don't use this.
 
@@ -2460,18 +2501,20 @@ The currently implemented features of the reference compiler are:
                         which is considered wildly unsafe and will be
                         obsoleted by language improvements.
 
+* `unsafe_no_drop_flag` - Allows use of the `#[unsafe_no_drop_flag]` attribute,
+                          which removes hidden flag added to a type that
+                          implements the `Drop` trait. The design for the
+                          `Drop` flag is subject to change, and this feature
+                          may be removed in the future.
+
 * `unmarked_api` - Allows use of items within a `#![staged_api]` crate
                    which have not been marked with a stability marker.
                    Such items should not be allowed by the compiler to exist,
                    so if you need this there probably is a compiler bug.
 
-* `associated_types` - Allows type aliases in traits. Experimental.
-
-* `no_std` - Allows the `#![no_std]` crate attribute, which disables the implicit
-             `extern crate std`. This typically requires use of the unstable APIs
-             behind the libstd "facade", such as libcore and libcollections. It
-             may also cause problems when using syntax extensions, including
-             `#[derive]`.
+* `visible_private_types` - Allows public APIs to expose otherwise private
+                            types, e.g. as the return type of a public function.
+                            This capability may be removed in the future.
 
 If a feature is promoted to a language feature, then all existing programs will
 start to receive compilation warnings about #[feature] directives which enabled
@@ -2591,9 +2634,8 @@ of any reference that points to it.
 
 When a [local variable](#memory-slots) is used as an
 [rvalue](#lvalues,-rvalues-and-temporaries) the variable will either be moved
-or copied, depending on its type. For types that contain [owning
-pointers](#pointer-types) or values that implement the special trait `Drop`,
-the variable is moved. All other types are copied.
+or copied, depending on its type. All values whose type implements `Copy` are
+copied, all others are moved.
 
 ### Literal expressions
 
@@ -2701,9 +2743,19 @@ items can bring new names into scopes and declared items are in scope for only
 the block itself.
 
 A block will execute each statement sequentially, and then execute the
-expression (if given). If the final expression is omitted, the type and return
-value of the block are `()`, but if it is provided, the type and return value
-of the block are that of the expression itself.
+expression (if given). If the block ends in a statement, its value is `()`:
+
+```
+let x: () = { println!("Hello."); };
+```
+
+If it ends in an expression, its value and type are that of the expression:
+
+```
+let x: i32 = { println!("Hello."); 5 };
+
+assert_eq!(5, x);
+```
 
 ### Method-call expressions
 
@@ -3502,9 +3554,6 @@ elements, respectively, in a parenthesized, comma-separated list.
 Because tuple elements don't have a name, they can only be accessed by
 pattern-matching.
 
-The members of a tuple are laid out in memory contiguously, in order specified
-by the tuple type.
-
 An example of a tuple type and its use:
 
 ```

src/doc/trpl/arrays-vectors-and-slices.md

@@ -49,8 +49,8 @@ languages.
 
 A *vector* is a dynamic or "growable" array, implemented as the standard
 library type [`Vec<T>`](../std/vec/) (we'll talk about what the `<T>` means
-later). Vectors are to arrays what `String` is to `&str`. You can create them
-with the `vec!` macro:
+later). Vectors always allocate their data on the heap. Vectors are to slices 
+what `String` is to `&str`. You can create them with the `vec!` macro:
 
 ```{rust}
 let v = vec![1, 2, 3]; // v: Vec<i32>

src/doc/trpl/compound-data-types.md

@@ -263,15 +263,12 @@ let four_is_smaller = four <= ten;
 let four_equals_ten = four == ten;
 ```
 
-This may seem rather limiting, particularly equality being invalid; in
-many cases however, it's unnecessary. Rust provides the [`match`][match]
-keyword, which will be examined in more detail in the next section, which
-often allows better and easier branch control than a series of `if`/`else`
-statements would. However, for our [game][game] we need the comparisons
-to work so we will utilize the `Ordering` `enum` provided by the standard
-library which supports such comparisons. It has this form:
+This may seem rather limiting, but it's a limitation which we can overcome.
+There are two ways: by implementing equality ourselves, or by using the
+[`match`][match] keyword. We don't know enough about Rust to implement equality
+yet, but we can use the `Ordering` enum from the standard library, which does:
 
-```{rust}
+```
 enum Ordering {
     Less,
     Equal,

src/doc/trpl/concurrency.md

@@ -171,7 +171,7 @@ use std::time::Duration;
 fn main() {
     let mut data = vec![1u32, 2, 3];
 
-    for i in 0 .. 2 {
+    for i in 0..2 {
         Thread::spawn(move || {
             data[i] += 1;
         });
@@ -211,7 +211,7 @@ use std::sync::Mutex;
 fn main() {
     let mut data = Mutex::new(vec![1u32, 2, 3]);
 
-    for i in 0 .. 2 {
+    for i in 0..2 {
         let data = data.lock().unwrap();
         Thread::spawn(move || {
             data[i] += 1;
@@ -262,7 +262,7 @@ use std::time::Duration;
 fn main() {
     let data = Arc::new(Mutex::new(vec![1u32, 2, 3]));
 
-    for i in (0us..2) {
+    for i in 0us..2 {
         let data = data.clone();
         Thread::spawn(move || {
             let mut data = data.lock().unwrap();
@@ -285,7 +285,7 @@ thread more closely:
 # use std::time::Duration;
 # fn main() {
 #     let data = Arc::new(Mutex::new(vec![1u32, 2, 3]));
-#     for i in (0us..2) {
+#     for i in 0us..2 {
 #         let data = data.clone();
 Thread::spawn(move || {
     let mut data = data.lock().unwrap();
@@ -323,7 +323,7 @@ fn main() {
 
     let (tx, rx) = mpsc::channel();
 
-    for _ in (0..10) {
+    for _ in 0..10 {
         let (data, tx) = (data.clone(), tx.clone());
 
         Thread::spawn(move || {
@@ -334,7 +334,7 @@ fn main() {
         });
     }
 
-    for _ in 0 .. 10 {
+    for _ in 0..10 {
         rx.recv();
     }
 }

src/doc/trpl/crates-and-modules.md

@@ -20,7 +20,7 @@ you to partition your code within the crate itself.
 
 As an example, let's make a *phrases* crate, which will give us various phrases
 in different languages. To keep things simple, we'll stick to "greetings" and
-"farewells" as two kinds of phrases, and use English and Japanese (日本語） as
+"farewells" as two kinds of phrases, and use English and Japanese (日本語) as
 two languages for those phrases to be in. We'll use this module layout:
 
 ```text

src/doc/trpl/documentation.md

@@ -1,4 +1,4 @@
-% Rust Documentation
+% Documentation
 
 `rustdoc` is the built-in tool for generating documentation. It integrates
 with the compiler to provide accurate hyperlinking between usage of types and
@@ -294,3 +294,26 @@ Documentation` on the first line).
 Like with a Rust crate, the `--test` argument will run the code
 examples to check they compile, and obeys any `--test-args` flags. The
 tests are named after the last `#` heading.
+
+# Re-exports
+
+Rustdoc will show the documentation for a publc re-export in both places:
+
+```{rust,ignore}
+extern crate foo;
+
+pub use foo::bar;
+```
+
+This will create documentation for `bar` both inside the documentation for
+the crate `foo`, as well as the documentation for your crate. It will use
+the same documentation in both places.
+
+This behavior can be supressed with `no_inline`:
+
+```{rust,ignore}
+extern crate foo;
+
+#[doc(no_inline)]
+pub use foo::bar;
+```