Auto merge of #43454 - Mark-Simulacrum:rollup, r=Mark-Simulacrum

Rollup of 11 pull requests

- Successful merges: #43297, #43322, #43342, #43361, #43366, #43374, #43379, #43401, #43421, #43428, #43446
- Failed merges:

Author: bors

configure

@@ -560,8 +560,8 @@ case "$CFG_RELEASE_CHANNEL" in
           *-pc-windows-gnu)
             ;;
           *)
-            CFG_ENABLE_DEBUGINFO_LINES=1
-            CFG_ENABLE_DEBUGINFO_ONLY_STD=1
+            enable_if_not_disabled debuginfo-lines
+            enable_if_not_disabled debuginfo-only-std
             ;;
         esac
 
@@ -572,8 +572,8 @@ case "$CFG_RELEASE_CHANNEL" in
           *-pc-windows-gnu)
             ;;
           *)
-            CFG_ENABLE_DEBUGINFO_LINES=1
-            CFG_ENABLE_DEBUGINFO_ONLY_STD=1
+            enable_if_not_disabled debuginfo-lines
+            enable_if_not_disabled debuginfo-only-std
             ;;
         esac
 	;;

src/doc/unstable-book/src/language-features/lang-items.md

@@ -194,6 +194,14 @@ pub extern fn rust_begin_panic(_msg: core::fmt::Arguments,
 }
 ```
 
+In many cases, you may need to manually link to the `compiler_builtins` crate
+when building a `no_std` binary. You may observe this via linker error messages
+such as "```undefined reference to `__rust_probestack'```". Using this crate
+also requires enabling the library feature `compiler_builtins_lib`. You can read
+more about this [here][compiler-builtins-lib].
+
+[compiler-builtins-lib]: library-features/compiler-builtins-lib.html
+
 ## More about the language items
 
 The compiler currently makes a few assumptions about symbols which are

src/doc/unstable-book/src/library-features/compiler-builtins-lib.md

@@ -0,0 +1,35 @@
+# `compiler_builtins_lib`
+
+The tracking issue for this feature is: None.
+
+------------------------
+
+This feature is required to link to the `compiler_builtins` crate which contains
+"compiler intrinsics". Compiler intrinsics are software implementations of basic
+operations like multiplication of `u64`s. These intrinsics are only required on
+platforms where these operations don't directly map to a hardware instruction.
+
+You should never need to explicitly link to the `compiler_builtins` crate when
+building "std" programs as `compiler_builtins` is already in the dependency
+graph of `std`. But you may need it when building `no_std` **binary** crates. If
+you get a *linker* error like:
+
+``` text
+$PWD/src/main.rs:11: undefined reference to `__aeabi_lmul'
+$PWD/src/main.rs:11: undefined reference to `__aeabi_uldivmod'
+```
+
+That means that you need to link to this crate.
+
+When you link to this crate, make sure it only appears once in your crate
+dependency graph. Also, it doesn't matter where in the dependency graph you
+place the `compiler_builtins` crate.
+
+<!-- NOTE(ignore) doctests don't support `no_std` binaries -->
+
+``` rust,ignore
+#![feature(compiler_builtins_lib)]
+#![no_std]
+
+extern crate compiler_builtins;
+```

src/liballoc/slice.rs

@@ -1252,12 +1252,13 @@ impl<T> [T] {
     ///
     /// # Current implementation
     ///
-    /// The current algorithm is based on Orson Peters' [pattern-defeating quicksort][pdqsort],
-    /// which is a quicksort variant designed to be very fast on certain kinds of patterns,
-    /// sometimes achieving linear time. It is randomized but deterministic, and falls back to
-    /// heapsort on degenerate inputs.
+    /// The current algorithm is based on [pattern-defeating quicksort][pdqsort] by Orson Peters,
+    /// which combines the fast average case of randomized quicksort with the fast worst case of
+    /// heapsort, while achieving linear time on slices with certain patterns. It uses some
+    /// randomization to avoid degenerate cases, but with a fixed seed to always provide
+    /// deterministic behavior.
     ///
-    /// It is generally faster than stable sorting, except in a few special cases, e.g. when the
+    /// It is typically faster than stable sorting, except in a few special cases, e.g. when the
     /// slice consists of several concatenated sorted sequences.
     ///
     /// # Examples
@@ -1286,12 +1287,13 @@ impl<T> [T] {
     ///
     /// # Current implementation
     ///
-    /// The current algorithm is based on Orson Peters' [pattern-defeating quicksort][pdqsort],
-    /// which is a quicksort variant designed to be very fast on certain kinds of patterns,
-    /// sometimes achieving linear time. It is randomized but deterministic, and falls back to
-    /// heapsort on degenerate inputs.
+    /// The current algorithm is based on [pattern-defeating quicksort][pdqsort] by Orson Peters,
+    /// which combines the fast average case of randomized quicksort with the fast worst case of
+    /// heapsort, while achieving linear time on slices with certain patterns. It uses some
+    /// randomization to avoid degenerate cases, but with a fixed seed to always provide
+    /// deterministic behavior.
     ///
-    /// It is generally faster than stable sorting, except in a few special cases, e.g. when the
+    /// It is typically faster than stable sorting, except in a few special cases, e.g. when the
     /// slice consists of several concatenated sorted sequences.
     ///
     /// # Examples
@@ -1323,12 +1325,13 @@ impl<T> [T] {
     ///
     /// # Current implementation
     ///
-    /// The current algorithm is based on Orson Peters' [pattern-defeating quicksort][pdqsort],
-    /// which is a quicksort variant designed to be very fast on certain kinds of patterns,
-    /// sometimes achieving linear time. It is randomized but deterministic, and falls back to
-    /// heapsort on degenerate inputs.
+    /// The current algorithm is based on [pattern-defeating quicksort][pdqsort] by Orson Peters,
+    /// which combines the fast average case of randomized quicksort with the fast worst case of
+    /// heapsort, while achieving linear time on slices with certain patterns. It uses some
+    /// randomization to avoid degenerate cases, but with a fixed seed to always provide
+    /// deterministic behavior.
     ///
-    /// It is generally faster than stable sorting, except in a few special cases, e.g. when the
+    /// It is typically faster than stable sorting, except in a few special cases, e.g. when the
     /// slice consists of several concatenated sorted sequences.
     ///
     /// # Examples

src/libcore/str/mod.rs

@@ -847,7 +847,7 @@ macro_rules! generate_pattern_iterators {
         internal:
             $internal_iterator:ident yielding ($iterty:ty);
 
-        // Kind of delgation - either single ended or double ended
+        // Kind of delegation - either single ended or double ended
         delegate $($t:tt)*
     } => {
         $(#[$forward_iterator_attribute])*

src/libcore/str/pattern.rs

@@ -83,7 +83,7 @@ pub enum SearchStep {
     /// Note that there might be more than one `Reject` between two `Match`es,
     /// there is no requirement for them to be combined into one.
     Reject(usize, usize),
-    /// Expresses that every byte of the haystack has been visted, ending
+    /// Expresses that every byte of the haystack has been visited, ending
     /// the iteration.
     Done
 }
@@ -101,7 +101,7 @@ pub enum SearchStep {
 /// the haystack. This enables consumers of this trait to
 /// slice the haystack without additional runtime checks.
 pub unsafe trait Searcher<'a> {
-    /// Getter for the underlaying string to be searched in
+    /// Getter for the underlying string to be searched in
     ///
     /// Will always return the same `&str`
     fn haystack(&self) -> &'a str;
@@ -1153,7 +1153,7 @@ impl TwoWaySearcher {
     // The maximal suffix is a possible critical factorization (u', v') of `arr`.
     //
     // Returns `i` where `i` is the starting index of v', from the back;
-    // returns immedately when a period of `known_period` is reached.
+    // returns immediately when a period of `known_period` is reached.
     //
     // `order_greater` determines if lexical order is `<` or `>`. Both
     // orders must be computed -- the ordering with the largest `i` gives

src/liblibc

@@ -0,0 +1,15 @@
+// Copyright 2017 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 <LICENSE-APACHE or
+// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
+// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
+// option. This file may not be copied, modified, or distributed
+// except according to those terms.
+
+fn main() {
+    println!("cargo:rerun-if-changed=build.rs");
+    println!("cargo:rerun-if-env-changed=CFG_LIBDIR_RELATIVE");
+    println!("cargo:rerun-if-env-changed=CFG_COMPILER_HOST_TRIPLE");
+}

src/librustc/build.rs

@@ -1708,7 +1708,7 @@ not apply to structs.
 representation of enums isn't strictly defined in Rust, and this attribute
 won't work on enums.
 
-`#[repr(simd)]` will give a struct consisting of a homogenous series of machine
+`#[repr(simd)]` will give a struct consisting of a homogeneous series of machine
 types (i.e. `u8`, `i32`, etc) a representation that permits vectorization via
 SIMD. This doesn't make much sense for enums since they don't consist of a
 single list of data.

src/librustc/diagnostics.rs

@@ -136,6 +136,10 @@ impl DefIndex {
     pub fn as_array_index(&self) -> usize {
         (self.0 & !DEF_INDEX_HI_START.0) as usize
     }
+
+    pub fn from_array_index(i: usize, address_space: DefIndexAddressSpace) -> DefIndex {
+        DefIndex::new(address_space.start() + i)
+    }
 }
 
 /// The start of the "high" range of DefIndexes.