---

yaml
---
r: 137153
b: refs/heads/release-prep
c: 06a6ba1
h: refs/heads/master
i:
  137151: 2b183f3
v: v3

Author: alexcrichton

[refs]

@@ -29,4 +29,4 @@ refs/tags/0.9: 36870b185fc5f5486636d4515f0e22677493f225
 refs/tags/0.10: ac33f2b15782272ae348dbd7b14b8257b2148b5a
 refs/heads/libuv-update-temp-branch: 6ed22c618766f1f2a2e108eef8ce3f51be0f70b7
 refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
-refs/heads/release-prep: 79d0e82f7386e9525e5232bf1083f74b0385838f
+refs/heads/release-prep: 06a6ba1d6fb37602cd3dff53491f96dc59aa3d94

branches/release-prep/.travis.yml

@@ -1,26 +1,60 @@
 # Use something that's not 'ruby' so we don't set up things like
-# RVM/bundler/ruby and whatnot. Right now 'rust' as a language actually
-# downloads a rust/cargo snapshot, which we don't really want for building rust.
+# RVM/bundler/ruby and whatnot. Right now 'rust' isn't a language on travis and
+# it treats unknown languages as ruby-like I believe.
 language: c
 
-# Make sure we've got an up-to-date g++ compiler to get past the LLVM configure
-# script.
+# Before we start doing anything, install a stock LLVM
 install:
-  - sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test
+  - sudo sh -c "echo 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise-3.4 main' >> /etc/apt/sources.list"
+  - sudo sh -c "echo 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise main' >> /etc/apt/sources.list"
+  - sudo sh -c "echo 'deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main' >> /etc/apt/sources.list"
+  - wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add -
   - sudo apt-get update -qq
-  - sudo apt-get install g++-4.7
+  - sudo apt-get install -qq --force-yes -y llvm-$LLVM_VERSION
+    llvm-${LLVM_VERSION}-dev clang-$LLVM_VERSION lldb-$LLVM_VERSION
 
-# The test suite is in general way too stressful for travis, especially in
-# terms of time limit and reliability. In the past we've tried to scale things
-# back to only build the stage1 compiler and run a subset of tests, but this
-# didn't end up panning out very well.
+
+# All of the llvm tools are suffixed with "-$VERS" which we don't want, so
+# symlink them all into a local directory and just use that
 #
-# As a result, we're just using travis to run `make tidy` now. It'll help
-# everyone find out about their trailing spaces early on!
+# FIXME: this shouldn't update the src/llvm sub-repo, that takes about a minute
+#        it's gotta download so much stuff.
 before_script:
-  - ./configure
-script:
-  - make tidy
+  - mkdir -p local-llvm/bin
+  - ln -nsf /usr/bin/llvm-config-$LLVM_VERSION local-llvm/bin/llvm-config
+  - ln -nsf /usr/bin/llvm-mc-$LLVM_VERSION local-llvm/bin/llvm-mc
+  - ln -nsf /usr/bin/llvm-as-$LLVM_VERSION local-llvm/bin/llvm-as
+  - ln -nsf /usr/bin/llvm-dis-$LLVM_VERSION local-llvm/bin/llvm-dis
+  - ln -nsf /usr/bin/llc-$LLVM_VERSION local-llvm/bin/llc
+  - ln -nsf /usr/include/llvm-$LLVM_VERSION local-llvm/include
+  - ./configure --disable-optimize-tests --llvm-root=`pwd`/local-llvm
+    --enable-fast-make --enable-clang
+
+# Tidy everything up first, then build a few things, and then run a few tests.
+# Note that this is meant to run in a "fairly small" amount of time, so this
+# isn't exhaustive at all.
+#
+# As a result of https://github.com/travis-ci/travis-ci/issues/1066, we run
+# everything in one large command instead of multiple commands.
+script: |
+  if [[ $TRAVIS_PULL_REQUEST != 'false' ]]; then
+    if [[ $LLVM_VERSION != '3.4' ]]; then exit 0; fi
+  fi &&
+  make tidy &&
+  make -j4 rustc-stage1 RUSTFLAGS='-Z time-passes' &&
+  make check-stage1-std check-stage1-rpass check-stage1-cfail check-stage1-rfail check-stage1-doc
+
+env:
+  global:
+    - NO_BENCH=1
+  matrix:
+    - LLVM_VERSION=3.3
+    - LLVM_VERSION=3.4
+
+# We track this ourselves, and in theory we don't have to update the LLVM repo
+# (but sadly we do right now anyway).
+git:
+  submodules: false
 
 notifications:
   email: false

branches/release-prep/configure

@@ -921,7 +921,6 @@ do
     make_dir $h/test/doc-guide-pointers
     make_dir $h/test/doc-guide-container
     make_dir $h/test/doc-guide-tasks
-    make_dir $h/test/doc-guide-plugin
     make_dir $h/test/doc-rust
 done
 

branches/release-prep/mk/ctags.mk

@@ -28,7 +28,7 @@ CTAGS_LOCATIONS=$(patsubst ${CFG_SRC_DIR}src/llvm,, \
 				$(patsubst ${CFG_SRC_DIR}src/rt/sundown,, \
 				$(patsubst ${CFG_SRC_DIR}src/rt/vg,, \
 				$(wildcard ${CFG_SRC_DIR}src/*) $(wildcard ${CFG_SRC_DIR}src/rt/*) \
-				)))))))))
+				)))))))))))
 CTAGS_OPTS=--options="${CFG_SRC_DIR}src/etc/ctags.rust" --languages=-javascript --recurse ${CTAGS_LOCATIONS}
 # We could use `--languages=Rust`, but there is value in producing tags for the
 # C++ parts of the code base too (at the time of writing, those are .h and .cpp

branches/release-prep/mk/docs.mk

@@ -27,7 +27,7 @@
 ######################################################################
 DOCS := index intro tutorial guide guide-ffi guide-macros guide-lifetimes \
 	guide-tasks guide-container guide-pointers guide-testing \
-	guide-runtime guide-plugin complement-bugreport \
+	guide-runtime complement-bugreport \
 	complement-lang-faq complement-design-faq complement-project-faq rust \
     rustdoc guide-unsafe guide-strings reference
 

branches/release-prep/mk/rt.mk

@@ -35,7 +35,7 @@
 # that's per-target so you're allowed to conditionally add files based on the
 # target.
 ################################################################################
-NATIVE_LIBS := rust_builtin hoedown morestack miniz context_switch \
+NATIVE_LIBS := rust_builtin hoedown uv_support morestack miniz context_switch \
 		rustrt_native rust_test_helpers
 
 # $(1) is the target triple
@@ -50,6 +50,7 @@ NATIVE_DEPS_hoedown_$(1) := hoedown/src/autolink.c \
 			hoedown/src/html_smartypants.c \
 			hoedown/src/stack.c \
 			hoedown/src/version.c
+NATIVE_DEPS_uv_support_$(1) := rust_uv.c
 NATIVE_DEPS_miniz_$(1) = miniz.c
 NATIVE_DEPS_rust_builtin_$(1) := rust_builtin.c \
 			rust_android_dummy.c

branches/release-prep/src/compiletest/compiletest.rs

@@ -9,7 +9,7 @@
 // except according to those terms.
 
 #![crate_type = "bin"]
-#![feature(phase)]
+#![feature(phase, slicing_syntax)]
 
 #![deny(warnings)]
 

branches/release-prep/src/compiletest/runtest.rs

@@ -874,7 +874,7 @@ fn check_error_patterns(props: &TestProps,
     if done { return; }
 
     let missing_patterns =
-        props.error_patterns.slice(next_err_idx, props.error_patterns.len());
+        props.error_patterns[next_err_idx..];
     if missing_patterns.len() == 1u {
         fatal_proc_rec(format!("error pattern '{}' not found!",
                               missing_patterns[0]).as_slice(),

branches/release-prep/src/doc/README.md

@@ -33,7 +33,7 @@ something like:
 pandoc --from=markdown --to=html5 --number-sections -o reference.html reference.md
 ~~~~
 
-(reference.md being the Rust Reference Manual.)
+(rust.md being the Rust Reference Manual.)
 
 The syntax for pandoc flavored markdown can be found at:
 http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown

branches/release-prep/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]: http://doc.rust-lang.org/rust.html#miscellaneous-attributes
 
 ## There is no GC
 
@@ -56,7 +56,7 @@ Types which are [`Sync`][sync] are thread-safe when multiple shared
 references to them are used concurrently. Types which are not `Sync` are not
 thread-safe, and thus when used in a global require unsafe code to use.
 
-[sync]: core/kinds/trait.Sync.html
+[sync]: http://doc.rust-lang.org/core/kinds/trait.Sync.html
 
 ### If mutable static items that implement `Sync` are safe, why is taking &mut SHARABLE unsafe?
 
@@ -139,8 +139,8 @@ and explicitly calling the `clone` method. Making user-defined copy operators
 explicit surfaces the underlying complexity, forcing the developer to opt-in
 to potentially expensive operations.
 
-[copy]: core/kinds/trait.Copy.html
-[clone]: core/clone/trait.Clone.html
+[copy]: http://doc.rust-lang.org/core/kinds/trait.Copy.html
+[clone]: http://doc.rust-lang.org/core/clone/trait.Clone.html
 
 ## No move constructors
 

branches/release-prep/src/doc/guide-lifetimes.md

@@ -305,17 +305,21 @@ copying.
 #     Circle(Point, f64),   // origin, radius
 #     Rectangle(Point, Size)  // upper-left, dimensions
 # }
+# static tau: f64 = 6.28;
 fn compute_area(shape: &Shape) -> f64 {
     match *shape {
-        Circle(_, radius) => std::f64::consts::PI * radius * radius,
+        Circle(_, radius) => 0.5 * tau * radius * radius,
         Rectangle(_, ref size) => size.w * size.h
     }
 }
 ~~~
 
 The first case matches against circles. Here, the pattern extracts the
 radius from the shape variant and the action uses it to compute the
-area of the circle.
+area of the circle. (Like any up-to-date engineer, we use the [tau
+circle constant][tau] and not that dreadfully outdated notion of pi).
+
+[tau]: http://www.math.utah.edu/~palais/pi.html
 
 The second match is more interesting. Here we match against a
 rectangle and extract its size: but rather than copy the `size`

branches/release-prep/src/doc/guide-macros.md

@@ -1,14 +1,5 @@
 % The Rust Macros Guide
 
-<div class="unstable-feature">
-<b>Warning:</b> There are currently various problems with invoking macros, how
-they interact with their environment, and how they are used outside of the
-location in which they are defined. Macro definitions are likely to change
-slightly in the future. For this reason, they are hidden behind the
-<code>macro_rules</code> <a href="reference.html#compiler-features">feature
-attribute</a>.
-</div>
-
 # Introduction
 
 Functions are the primary tool that programmers can use to build abstractions.
@@ -457,66 +448,6 @@ fn main() {
 The two `'x` names did not clash, which would have caused the loop
 to print "I am never printed" and to run forever.
 
-# Scoping and macro import/export
-
-Macros occupy a single global namespace. The interaction with Rust's system of
-modules and crates is somewhat complex.
-
-Definition and expansion of macros both happen in a single depth-first,
-lexical-order traversal of a crate's source. So a macro defined at module scope
-is visible to any subsequent code in the same module, which includes the body
-of any subsequent child `mod` items.
-
-If a module has the `macro_escape` attribute, its macros are also visible in
-its parent module after the child's `mod` item. If the parent also has
-`macro_escape` then the macros will be visible in the grandparent after the
-parent's `mod` item, and so forth.
-
-Independent of `macro_escape`, the `macro_export` attribute controls visibility
-between crates.  Any `macro_rules!` definition with the `macro_export`
-attribute will be visible to other crates that have loaded this crate with
-`phase(plugin)`. There is currently no way for the importing crate to control
-which macros are imported.
-
-An example:
-
-```rust
-# #![feature(macro_rules)]
-macro_rules! m1 (() => (()))
-
-// visible here: m1
-
-mod foo {
-    // visible here: m1
-
-    #[macro_export]
-    macro_rules! m2 (() => (()))
-
-    // visible here: m1, m2
-}
-
-// visible here: m1
-
-macro_rules! m3 (() => (()))
-
-// visible here: m1, m3
-
-#[macro_escape]
-mod bar {
-    // visible here: m1, m3
-
-    macro_rules! m4 (() => (()))
-
-    // visible here: m1, m3, m4
-}
-
-// visible here: m1, m3, m4
-# fn main() { }
-```
-
-When this library is loaded with `#[phase(plugin)] extern crate`, only `m2`
-will be imported.
-
 # A final note
 
 Macros, as currently implemented, are not for the faint of heart. Even
@@ -526,10 +457,3 @@ tricky. Invoking the `log_syntax!` macro can help elucidate intermediate
 states, invoking `trace_macros!(true)` will automatically print those
 intermediate states out, and passing the flag `--pretty expanded` as a
 command-line argument to the compiler will show the result of expansion.
-
-If Rust's macro system can't do what you need, you may want to write a
-[compiler plugin](guide-plugin.html) instead. Compared to `macro_rules!`
-macros, this is significantly more work, the interfaces are much less stable,
-and the warnings about debugging apply ten-fold. In exchange you get the
-flexibility of running arbitrary Rust code within the compiler. Syntax
-extension plugins are sometimes called "procedural macros" for this reason.