---

yaml
---
r: 231794
b: refs/heads/auto
c: d7afefc
h: refs/heads/master
v: v3

Author: Manishearth

[refs]

@@ -8,7 +8,7 @@ refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 8175dce5172bfb66dd6bc8e57175a5102acb1f94
+refs/heads/auto: d7afefcbd18f78edad147aad250571d80effd4d0
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336
 refs/tags/0.2: 1754d02027f2924bed83b0160ee340c7f41d5ea1

branches/auto/configure

@@ -1180,16 +1180,27 @@ do
             # MSVC requires cmake because that's how we're going to build LLVM
             probe_need CFG_CMAKE cmake
 
+            # There are three builds of cmake on windows: MSVC, MinGW and Cygwin
+            # The Cygwin build does not have generators for Visual Studio, so
+            # detect that here and error.
+            if ! "$CFG_CMAKE" --help | sed -n '/^Generators/,$p' | grep 'Visual Studio' > /dev/null
+            then
+                err "cmake does not support Visual Studio generators.\n\n \
+                     This is likely due to it being an msys/cygwin build of cmake, \
+                     rather than the required windows version, built using MinGW \
+                     or Visual Studio."
+            fi
+
             # Use the REG program to figure out where VS is installed
             # We need to figure out where cl.exe and link.exe are, so we do some
             # munging and some probing here. We also look for the default
             # INCLUDE and LIB variables for MSVC so we can set those in the
             # build system as well.
-            install=$(reg QUERY \
+            install=$(cmd //c reg QUERY \
                        'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0' \
                        -v InstallDir)
             if [ -z "$install" ]; then
-              install=$(reg QUERY \
+              install=$(cmd //c reg QUERY \
                          'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0' \
                          -v InstallDir)
             fi
@@ -1222,9 +1233,9 @@ do
             eval CFG_MSVC_LINK_$bits="\"$bindir/link.exe\""
 
             vcvarsall="${CFG_MSVC_ROOT}/VC/vcvarsall.bat"
-            include_path=$(cmd /c "\"$vcvarsall\" $msvc_part && cmd /c echo %INCLUDE%")
+            include_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !INCLUDE!)
             need_ok "failed to learn about MSVC's INCLUDE"
-            lib_path=$(cmd /c "\"$vcvarsall\" $msvc_part && cmd /c echo %LIB%")
+            lib_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !LIB!)
             need_ok "failed to learn about MSVC's LIB"
 
             eval CFG_MSVC_INCLUDE_PATH_${bits}="\"$include_path\""

branches/auto/src/doc/trpl/method-syntax.md

@@ -7,7 +7,7 @@ can be awkward. Consider this code:
 baz(bar(foo));
 ```
 
-We would read this left-to right, and so we see ‘baz bar foo’. But this isn’t the
+We would read this left-to-right, and so we see ‘baz bar foo’. But this isn’t the
 order that the functions would get called in, that’s inside-out: ‘foo bar baz’.
 Wouldn’t it be nice if we could do this instead?
 
@@ -45,17 +45,17 @@ This will print `12.566371`.
 
 
 
-We’ve made a struct that represents a circle. We then write an `impl` block,
+We’ve made a `struct` that represents a circle. We then write an `impl` block,
 and inside it, define a method, `area`.
 
-Methods take a  special first parameter, of which there are three variants:
+Methods take a special first parameter, of which there are three variants:
 `self`, `&self`, and `&mut self`. You can think of this first parameter as
 being the `foo` in `foo.bar()`. The three variants correspond to the three
 kinds of things `foo` could be: `self` if it’s just a value on the stack,
 `&self` if it’s a reference, and `&mut self` if it’s a mutable reference.
 Because we took the `&self` parameter to `area`, we can use it just like any
 other parameter. Because we know it’s a `Circle`, we can access the `radius`
-just like we would with any other struct. 
+just like we would with any other `struct`. 
 
 We should default to using `&self`, as you should prefer borrowing over taking
 ownership, as well as taking immutable references over mutable ones. Here’s an
@@ -120,12 +120,12 @@ Check the return type:
 ```rust
 # struct Circle;
 # impl Circle {
-fn grow(&self) -> Circle {
+fn grow(&self, increment: f64) -> Circle {
 # Circle } }
 ```
 
 We just say we’re returning a `Circle`. With this method, we can grow a new
-circle to any arbitrary size.
+`Circle` to any arbitrary size.
 
 # Associated functions
 
@@ -161,7 +161,7 @@ methods’.
 
 # Builder Pattern
 
-Let’s say that we want our users to be able to create Circles, but we will
+Let’s say that we want our users to be able to create `Circle`s, but we will
 allow them to only set the properties they care about. Otherwise, the `x`
 and `y` attributes will be `0.0`, and the `radius` will be `1.0`. Rust doesn’t
 have method overloading, named arguments, or variable arguments. We employ
@@ -224,7 +224,7 @@ fn main() {
 }
 ```
 
-What we’ve done here is make another struct, `CircleBuilder`. We’ve defined our
+What we’ve done here is make another `struct`, `CircleBuilder`. We’ve defined our
 builder methods on it. We’ve also defined our `area()` method on `Circle`. We
 also made one more method on `CircleBuilder`: `finalize()`. This method creates
 our final `Circle` from the builder. Now, we’ve used the type system to enforce

branches/auto/src/etc/platform-intrinsics/aarch64.json

@@ -336,6 +336,48 @@
             "ret": "i8",
             "args": ["0"]
         },
+        {
+            "intrinsic": "ld2{0[0].width}_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld2.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);2]","[f(32-64);2]"],
+            "args": ["0.0SPc/0.0"]
+        },
+        {
+            "intrinsic": "ld3{0[0].width}_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld3.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);3]","[f(32-64);3]"],
+            "args": ["0.0SPc/0.0"]
+        },
+        {
+            "intrinsic": "ld4{0[0].width}_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld4.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);4]","[f(32-64);4]"],
+            "args": ["0.0SPc/0.0"]
+        },
+        {
+            "intrinsic": "ld2{0[0].width}_dup_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld2.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);2]","[f(32-64);2]"],
+            "args": ["0.0SPc"]
+        },
+        {
+            "intrinsic": "ld3{0[0].width}_dup_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld3.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);3]","[f(32-64);3]"],
+            "args": ["0.0SPc"]
+        },
+        {
+            "intrinsic": "ld4{0[0].width}_dup_{0[0].data_type}",
+            "width": [64, 128],
+            "llvm": "ld4.{0[0].llvm_name}.{1.llvm_name}",
+            "ret": ["[i(8-64);4]","[f(32-64);4]"],
+            "args": ["0.0SPc"]
+        },
         {
             "intrinsic": "padd{0.width}_{0.data_type}",
             "width": [64, 128],