Merge branch 'master' into

Author: nrc

AUTHORS.txt

@@ -518,6 +518,7 @@ Luke Francl <[email protected]>
 Luke Metz <[email protected]>
 Luke Steensen <[email protected]>
 Luqman Aden <[email protected]>
+Łukasz Niemier <[email protected]>
 Magnus Auvinen <[email protected]>
 Mahmut Bulut <[email protected]>
 Makoto Nakashima <[email protected]>
@@ -997,5 +998,4 @@ xales <[email protected]>
 zofrex <[email protected]>
 zslayton <[email protected]>
 zzmp <[email protected]>
-Łukasz Niemier <[email protected]>
 克雷 <[email protected]>

configure

@@ -19,6 +19,11 @@ err() {
     exit 1
 }
 
+run() {
+    msg "$@"
+    "$@"
+}
+
 need_ok() {
     if [ $? -ne 0 ]
     then
@@ -36,8 +41,7 @@ need_cmd() {
 make_dir() {
     if [ ! -d $1 ]
     then
-        msg "mkdir -p $1"
-        mkdir -p $1
+        run mkdir -p $1
     fi
 }
 
@@ -46,8 +50,7 @@ copy_if_changed() {
     then
         msg "leaving $2 unchanged"
     else
-        msg "cp $1 $2"
-        cp -f $1 $2
+        run cp -f $1 $2
         chmod u-w $2 # make copied artifact read-only
     fi
 }
@@ -57,8 +60,7 @@ move_if_changed() {
     then
         msg "leaving $2 unchanged"
     else
-        msg "mv $1 $2"
-        mv -f $1 $2
+        run mv -f $1 $2
         chmod u-w $2 # make moved artifact read-only
     fi
 }
@@ -544,7 +546,7 @@ fi
 BOOL_OPTIONS=""
 VAL_OPTIONS=""
 
-opt debug 0 "debug mode"
+opt debug 0 "debug mode; disables optimization unless \`--enable-optimize\` given"
 opt valgrind 0 "run tests with valgrind (memcheck by default)"
 opt helgrind 0 "run tests with helgrind instead of memcheck"
 opt valgrind-rpass 1 "run rpass-valgrind tests with valgrind"
@@ -733,6 +735,20 @@ then
    probe CFG_JAVAC            javac
 fi
 
+# the valgrind rpass tests will fail if you don't have a valgrind, but they're
+# only disabled if you opt out.
+if [ -z "$CFG_VALGRIND" ]
+then
+    # If the user has explicitly asked for valgrind tests, then fail
+    if [ -n "$CFG_ENABLE_VALGRIND" ] && [ -n "$CFG_ENABLE_VALGRIND_PROVIDED" ]
+    then
+        err "No valgrind present, but valgrind tests explicitly requested"
+    else
+        CFG_DISABLE_VALGRIND_RPASS=1
+        putvar CFG_DISABLE_VALGRIND_RPASS
+    fi
+fi
+
 if [ ! -z "$CFG_GDB" ]
 then
     # Store GDB's version
@@ -844,7 +860,7 @@ then
     CFG_OSX_GCC_VERSION=$("$CFG_GCC" --version 2>&1 | grep "Apple LLVM version")
     if [ $? -eq 0 ]
     then
-        step_msg "on OS X 10.9, forcing use of clang"
+        step_msg "on OS X >=10.9, forcing use of clang"
         CFG_ENABLE_CLANG=1
     else
         if [ $("$CFG_GCC" --version 2>&1 | grep -c ' 4\.[0-6]') -ne 0 ]; then

mk/crates.mk

@@ -58,7 +58,7 @@ RUSTC_CRATES := rustc rustc_typeck rustc_borrowck rustc_resolve rustc_driver \
                 rustc_data_structures
 HOST_CRATES := syntax $(RUSTC_CRATES) rustdoc fmt_macros
 CRATES := $(TARGET_CRATES) $(HOST_CRATES)
-TOOLS := compiletest rustdoc rustc rustbook
+TOOLS := compiletest rustdoc rustc rustbook error-index-generator
 
 DEPS_core :=
 DEPS_libc := core
@@ -107,10 +107,12 @@ TOOL_DEPS_compiletest := test getopts
 TOOL_DEPS_rustdoc := rustdoc
 TOOL_DEPS_rustc := rustc_driver
 TOOL_DEPS_rustbook := std rustdoc
+TOOL_DEPS_error-index-generator := rustdoc syntax serialize
 TOOL_SOURCE_compiletest := $(S)src/compiletest/compiletest.rs
 TOOL_SOURCE_rustdoc := $(S)src/driver/driver.rs
 TOOL_SOURCE_rustc := $(S)src/driver/driver.rs
 TOOL_SOURCE_rustbook := $(S)src/rustbook/main.rs
+TOOL_SOURCE_error-index-generator := $(S)src/error-index-generator/main.rs
 
 ONLY_RLIB_core := 1
 ONLY_RLIB_libc := 1

mk/dist.mk

@@ -52,6 +52,7 @@ PKG_FILES := \
       doc                                      \
       driver                                   \
       etc                                      \
+      error-index-generator                    \
       $(foreach crate,$(CRATES),lib$(crate))   \
       libcollectionstest                       \
       libcoretest                              \

mk/docs.mk

@@ -71,9 +71,13 @@ RUSTBOOK_EXE = $(HBIN2_H_$(CFG_BUILD))/rustbook$(X_$(CFG_BUILD))
 # ./configure
 RUSTBOOK = $(RPATH_VAR2_T_$(CFG_BUILD)_H_$(CFG_BUILD)) $(RUSTBOOK_EXE)
 
+# The error-index-generator executable...
+ERR_IDX_GEN_EXE = $(HBIN2_H_$(CFG_BUILD))/error-index-generator$(X_$(CFG_BUILD))
+ERR_IDX_GEN = $(RPATH_VAR2_T_$(CFG_BUILD)_H_$(CFG_BUILD)) $(ERR_IDX_GEN_EXE)
+
 D := $(S)src/doc
 
-DOC_TARGETS := trpl style
+DOC_TARGETS := trpl style error-index
 COMPILER_DOC_TARGETS :=
 DOC_L10N_TARGETS :=
 
@@ -288,3 +292,9 @@ doc/style/index.html: $(RUSTBOOK_EXE) $(wildcard $(S)/src/doc/style/*.md) | doc/
 	@$(call E, rustbook: $@)
 	$(Q)rm -rf doc/style
 	$(Q)$(RUSTBOOK) build $(S)src/doc/style doc/style
+
+error-index: doc/error-index.html
+
+doc/error-index.html: $(ERR_IDX_GEN_EXE) | doc/
+	$(Q)$(call E, error-index-generator: $@)
+	$(Q)$(ERR_IDX_GEN)

mk/main.mk

@@ -195,6 +195,7 @@ ifndef CFG_DISABLE_VALGRIND_RPASS
   $(info cfg: valgrind-rpass command set to $(CFG_VALGRIND))
   CFG_VALGRIND_RPASS :=$(CFG_VALGRIND)
 else
+  $(info cfg: disabling valgrind run-pass tests)
   CFG_VALGRIND_RPASS :=
 endif
 

mk/prepare.mk

@@ -70,7 +70,7 @@ define PREPARE_MAN
 	$(Q)$(PREPARE_MAN_CMD) $(PREPARE_SOURCE_MAN_DIR)/$(1) $(PREPARE_DEST_MAN_DIR)/$(1)
 endef
 
-PREPARE_TOOLS = $(filter-out compiletest rustbook, $(TOOLS))
+PREPARE_TOOLS = $(filter-out compiletest rustbook error-index-generator, $(TOOLS))
 
 
 # $(1) is tool

src/compiletest/compiletest.rs

@@ -226,15 +226,15 @@ pub fn run_tests(config: &Config) {
         }
 
         // android debug-info test uses remote debugger
-        // so, we test 1 task at once.
+        // so, we test 1 thread at once.
         // also trying to isolate problems with adb_run_wrapper.sh ilooping
         env::set_var("RUST_TEST_THREADS","1");
     }
 
     match config.mode {
         DebugInfoLldb => {
             // Some older versions of LLDB seem to have problems with multiple
-            // instances running in parallel, so only run one test task at a
+            // instances running in parallel, so only run one test thread at a
             // time.
             env::set_var("RUST_TEST_THREADS", "1");
         }
@@ -269,7 +269,7 @@ pub fn test_opts(config: &Config) -> test::TestOpts {
         run_ignored: config.run_ignored,
         logfile: config.logfile.clone(),
         run_tests: true,
-        run_benchmarks: true,
+        bench_benchmarks: true,
         nocapture: env::var("RUST_TEST_NOCAPTURE").is_ok(),
         color: test::AutoColor,
     }

src/doc/complement-design-faq.md

@@ -39,7 +39,7 @@ representation as a primitive. This allows using Rust `enum`s in FFI where C
 `enum`s are also used, for most use cases. The attribute can also be applied
 to `struct`s to get the same layout as a C struct would.
 
-[repr]: reference.html#miscellaneous-attributes
+[repr]: reference.html#ffi-attributes
 
 ## There is no GC
 
@@ -96,7 +96,7 @@ code should need to run is a stack.
 possibility is covered by the `match`, adding further variants to the `enum`
 in the future will prompt a compilation failure, rather than runtime panic.
 Second, it makes cost explicit. In general, the only safe way to have a
-non-exhaustive match would be to panic the task if nothing is matched, though
+non-exhaustive match would be to panic the thread if nothing is matched, though
 it could fall through if the type of the `match` expression is `()`. This sort
 of hidden cost and special casing is against the language's philosophy. It's
 easy to ignore certain cases by using the `_` wildcard:

src/doc/complement-lang-faq.md

@@ -62,15 +62,15 @@ Data values in the language can only be constructed through a fixed set of initi
 * There is no global inter-crate namespace; all name management occurs within a crate.
  * Using another crate binds the root of _its_ namespace into the user's namespace.
 
-## Why is panic unwinding non-recoverable within a task? Why not try to "catch exceptions"?
+## Why is panic unwinding non-recoverable within a thread? Why not try to "catch exceptions"?
 
-In short, because too few guarantees could be made about the dynamic environment of the catch block, as well as invariants holding in the unwound heap, to be able to safely resume; we believe that other methods of signalling and logging errors are more appropriate, with tasks playing the role of a "hard" isolation boundary between separate heaps.
+In short, because too few guarantees could be made about the dynamic environment of the catch block, as well as invariants holding in the unwound heap, to be able to safely resume; we believe that other methods of signalling and logging errors are more appropriate, with threads playing the role of a "hard" isolation boundary between separate heaps.
 
 Rust provides, instead, three predictable and well-defined options for handling any combination of the three main categories of "catch" logic:
 
 * Failure _logging_ is done by the integrated logging subsystem.
-* _Recovery_ after a panic is done by trapping a task panic from _outside_
-  the task, where other tasks are known to be unaffected.
+* _Recovery_ after a panic is done by trapping a thread panic from _outside_
+  the thread, where other threads are known to be unaffected.
 * _Cleanup_ of resources is done by RAII-style objects with destructors.
 
 Cleanup through RAII-style destructors is more likely to work than in catch blocks anyways, since it will be better tested (part of the non-error control paths, so executed all the time).
@@ -91,8 +91,8 @@ We don't know if there's an obvious, easy, efficient, stock-textbook way of supp
 
 There's a lot of debate on this topic; it's easy to find a proponent of default-sync or default-async communication, and there are good reasons for either. Our choice rests on the following arguments:
 
-* Part of the point of isolating tasks is to decouple tasks from one another, such that assumptions in one task do not cause undue constraints (or bugs, if violated!) in another. Temporal coupling is as real as any other kind; async-by-default relaxes the default case to only _causal_ coupling.
-* Default-async supports buffering and batching communication, reducing the frequency and severity of task-switching and inter-task / inter-domain synchronization.
+* Part of the point of isolating threads is to decouple threads from one another, such that assumptions in one thread do not cause undue constraints (or bugs, if violated!) in another. Temporal coupling is as real as any other kind; async-by-default relaxes the default case to only _causal_ coupling.
+* Default-async supports buffering and batching communication, reducing the frequency and severity of thread-switching and inter-thread / inter-domain synchronization.
 * Default-async with transmittable channels is the lowest-level building block on which more-complex synchronization topologies and strategies can be built; it is not clear to us that the majority of cases fit the 2-party full-synchronization pattern rather than some more complex multi-party or multi-stage scenario. We did not want to force all programs to pay for wiring the former assumption into all communications.
 
 ## Why are channels half-duplex (one-way)?
@@ -109,7 +109,7 @@ This does mean that indexed access to a Unicode codepoint inside a `str` value i
 * Most "character oriented" operations on text only work under very restricted language assumptions sets such as "ASCII-range codepoints only". Outside ASCII-range, you tend to have to use a complex (non-constant-time) algorithm for determining linguistic-unit (glyph, word, paragraph) boundaries anyways. We recommend using an "honest" linguistically-aware, Unicode-approved algorithm.
 * The `char` type is UCS4. If you honestly need to do a codepoint-at-a-time algorithm, it's trivial to write a `type wstr = [char]`, and unpack a `str` into it in a single pass, then work with the `wstr`. In other words: the fact that the language is not "decoding to UCS4 by default" shouldn't stop you from decoding (or re-encoding any other way) if you need to work with that encoding.
 
-## Why are strings, vectors etc. built-in types rather than (say) special kinds of trait/impl?
+## Why are `str`s, slices, arrays etc. built-in types rather than (say) special kinds of trait/impl?
 
 In each case there is one or more operator, literal constructor, overloaded use or integration with a built-in control structure that makes us think it would be awkward to phrase the type in terms of more-general type constructors. Same as, say, with numbers! But this is partly an aesthetic call, and we'd be willing to look at a worked-out proposal for eliminating or rephrasing these special cases.
 

src/doc/grammar.md

@@ -176,9 +176,15 @@ excluded from the `ident` rule.
 
 ```antlr
 lit_suffix : ident;
-literal : [ string_lit | char_lit | byte_string_lit | byte_lit | num_lit ] lit_suffix ?;
+literal : [ string_lit | char_lit | byte_string_lit | byte_lit | num_lit | bool_lit ] lit_suffix ?;
 ```
 
+The optional `lit_suffix` production is only used for certain numeric literals,
+but is reserved for future extension. That is, the above gives the lexical
+grammar, but a Rust parser will reject everything but the 12 special cases
+mentioned in [Number literals](reference.html#number-literals) in the
+reference.
+
 #### Character and string literals
 
 ```antlr
@@ -238,7 +244,9 @@ dec_lit : [ dec_digit | '_' ] + ;
 
 #### Boolean literals
 
-**FIXME:** write grammar
+```antlr
+bool_lit : [ "true" | "false" ] ;
+```
 
 The two values of the boolean type are written `true` and `false`.
 
@@ -297,7 +305,7 @@ transcriber : '(' transcriber * ')' | '[' transcriber * ']'
 
 ```antlr
 item : mod_item | fn_item | type_item | struct_item | enum_item
-     | static_item | trait_item | impl_item | extern_block ;
+     | const_item | static_item | trait_item | impl_item | extern_block ;
 ```
 
 ### Type Parameters
@@ -321,7 +329,7 @@ view_item : extern_crate_decl | use_decl ;
 
 ```antlr
 extern_crate_decl : "extern" "crate" crate_name
-crate_name: ident | ( string_lit as ident )
+crate_name: ident | ( ident "as" ident )
 ```
 
 ##### Use declarations
@@ -369,6 +377,10 @@ path_item : ident | "mod" ;
 
 **FIXME:** grammar?
 
+### Enumerations
+
+**FIXME:** grammar?
+
 ### Constant items
 
 ```antlr
@@ -777,8 +789,8 @@ bound := path | lifetime
 
 ### Boxes
 
-## Tasks
+## Threads
 
-### Communication between tasks
+### Communication between threads
 
-### Task lifecycle
+### Thread lifecycle