Update VecDeque documentation to specify direction of index 0 (#34920)

try to recover the non-matching types in projection errors

The type equation in projection takes place under a binder and a snapshot, which
we can't easily take types out of. Instead, when encountering a projection error,
try to re-do the projection and find the type error then.

This fails to produce a sane type error when the failure was a "leak_check" failure.
I can't think of a sane way to show *these*, so I just left them use the old crappy
representation, and added a test to make sure we don't break them.

remove the now-unused multiline error code

refactor constant evaluation error reporting

Refactor constant evaluation to use a single error reporting function
that reports a type-error-like message.

Also, unify all error codes with the "constant evaluation error" message
to just E0080, and similarly for a few other duplicate codes. The old
situation was a total mess, and now that we have *something* we can
further iterate on the UX.

switch projection errors to use the new type error messages

Unfortunately, projection errors do not come with a nice set of
mismatched types. This is because the type equality check occurs
within a higher-ranked context. Therefore, only the type error
is reported. This is ugly but was always the situation.

I will introduce better errors for the lower-ranked case in
another commit.

Fixes the last known occurence of #31173

switch compare_method to new-style trait error reporting

refactor type error reporting

remove rustc_typeck::same_type_err

remove never-called type-error reporting functions

Auto merge of #34771 - murarth:string-insert-str, r=alexcrichton

Add method `String::insert_str`

improve const eval error reporting on "" and b"" casts

Auto merge of #34724 - mitchmindtree:mpsc_receiver_try_recv, r=alexcrichton

Add a method to the mpsc::Receiver for producing a non-blocking iterator

Currently, the `mpsc::Receiver` offers methods for receiving values in both blocking (`recv`) and non-blocking (`try_recv`) flavours. However only blocking iteration over values is supported. This PR adds a non-blocking iterator to complement the `try_recv` method, just as the blocking iterator complements the `recv` method.

Use-case
-------------

I predominantly use rust in my work on real-time systems and in particular real-time audio generation/processing. I use `mpsc::channel`s to communicate between threads in a purely non-blocking manner. I.e. I might send messages from the GUI thread to the audio thread to update the state of the dsp-graph, or from the audio thread to the GUI thread to display the RMS of each node. These are just a couple examples (I'm probably using 30+ channels across my various projects). I almost exclusively use the `mpsc::Receiver::try_recv` method to avoid blocking any of the real-time threads and causing unwanted glitching/stuttering. Now that I mention it, I can't think of a single time that I personally have used the `recv` method (though I can of course see why it would be useful, and perhaps the common case for many people).

As a result of this experience, I can't help but feel there is a large hole in the `Receiver` API.

| blocking | non-blocking |
|------------|--------------------|
| `recv` | `try_recv` |
| `iter` | 🙀   |

For the most part, I've been working around this using `while let Ok(v) = r.try_recv() { ... }`, however as nice as this is, it is clearly no match for the Iterator API.

As an example, in the majority of my channel use cases I only want to check for *n* number of messages before breaking from the loop so that I don't miss the audio IO callback or hog the GUI thread for too long when an unexpectedly large number of messages are sent. Currently, I have to write something like this:

```rust
let mut take = 100;
while let Ok(msg) = rx.try_recv() {
    // Do stuff with msg
    if take == 0 {
        break;
    }
    take -= 1;
}
```

or wrap the `try_recv` call in a `Range<usize>`/`FilterMap` iterator combo.

On the other hand, this PR would allow for the following:

```rust
for msg in rx.try_iter().take(100) {
    // Do stuff with msg
}
```

I imagine this might also be useful to game devs, embedded or anyone doing message passing across real-time threads.

Readding lifetime parameters and removing allocation

Auto merge of #34715 - scottcarr:mir-test, r=nikomatsakis

Add MIR Optimization Tests

I've starting working on the infrastructure for testing MIR optimizations.

The plan now is to have a set of test cases (written in Rust), compile them with -Z dump-mir, and check the MIR before and after each pass.

Auto merge of #34544 - 3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton

feat: reinterpret `precision` field for strings

This commit changes the behavior of formatting string arguments with both width and precision fields set.

Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.

This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored.

For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```

This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char.

__However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.

Avoid processing `feature`s on unconfigured crates.

switch mipsel-musl to soft float

Fix nits

Remove unused methods from MultiSpan

doc: add missing pause

Fix ICE happening when unresolved imports are used in patterns

Auto merge of #34939 - GuillaumeGomez:rollup, r=GuillaumeGomez

Rollup of 7 pull requests

- Successful merges: #34854, #34855, #34880, #34895, #34911, #34921, #34930
- Failed merges: #33951, #34850

Fix issue in receiver_try_iter test where response sender would panic instead of break from the loop

Rollup merge of #34937 - GuillaumeGomez:hash_map_entry_debug, r=apasel422

Add debug for hash_map::{Entry, VacantEntry, OccupiedEntry}

r? @alexcrichton

Rollup merge of #34930 - frewsxcv:vec-as-slice, r=steveklabnik

Add doc examples for `Vec::{as_slice,as_mut_slice}`.

None

Rollup merge of #34921 - GuillaumeGomez:css_fix, r=steveklabnik

[CSS] Fix unwanted top margin for toggle wrapper

Fixes top margin.

Before:


After (check "A view into a single entry in map" toggle wrapper more precisely):


r? @steveklabnik

Rollup merge of #34919 - GuillaumeGomez:btree_map_doc, r=steveklabnik

Add doc for btree_map types

Part of #29348.

r? @steveklabnik

Rollup merge of #34911 - frewsxcv:vec-set-len, r=steveklabnik

Rewrite/expand doc examples for `Vec::set_len`.

None

Rollup merge of #34910 - alexcrichton:hard-float-mips, r=brson

rustc: Remove soft-float from MIPS targets

Right now two MIPS targets in the compiler, `mips-unknown-linux-{gnu,musl}` both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the `-C soft-float` codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in #9617), and nowadays it's more appropriate to be done through a codegen
option.

This is motivated by #34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until #34841 landed because otherwise we would fail to compile C code as the
`-msoft-float` option wouldn't work.

Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.

If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!

Rollup merge of #34895 - mark-buer:patch-1, r=steveklabnik

Remove rustdoc reference to `walk_dir`

Rollup merge of #34890 - oconnor663:addassign, r=brson

implement AddAssign for String

Currently `String` implements `Add` but not `AddAssign`. This PR fills in that gap.

I played around with having `AddAssign` (and `Add` and `push_str`) take `AsRef<str>` instead of `&str`, but it looks like that breaks arguments that implement `Deref<Target=str>` and not `AsRef<str>`. Comments in [`libcore/convert.rs`](https://github.com/rust-lang/rust/blob/master/src/libcore/convert.rs#L207-L213) make it sound like we could fix this with a blanket impl eventually. Does anyone know what's blocking that?

Rollup merge of #34880 - xitep:master, r=steveklabnik

Make .enumerate() example self-explanatory

Should resolve #34624

Rollup merge of #34855 - GuillaumeGomez:vec_deque_doc, r=steveklabnik

Add examples for VecDeque

Part of #29348.

r? @steveklabnik

Rollup merge of #34854 - GuillaumeGomez:linked_list_doc, r=steveklabnik

Add examples for LinkedList

Part of #29348.

r? @steveklabnik

Rollup merge of #34828 - seanmonstar:into-opton, r=alexcrichton

core: impl From<T> for Option<T>

First, the semantics of this `impl` seem spot on. If I have a value `T`, and I wish to make a `Option<T>`, then `Option::from(val)` should always give `Some(val)`.

Second, this allows improvement for several APIs that currently take `Option<T>` as arguments. Consider:

```rust
fn set_read_timeout(&mut self, timeout: Option<u32>) {
    // ...
}

x.set_read_timeout(Some(30));
x.set_read_timeout(Some(10));
x.set_read_timeout(None);
```

With this `impl`:

```rust
fn set_read_timeout<T: Into<Option<u32>>>(&mut self, timeout: T) {
    let timeout = timeout.into();
    // ...
}

x.set_read_timeout(30);
x.set_read_timeout(10);
x.set_read_timeout(Some(10)); // backwards compatible
x.set_read_timeout(None);
```

The change to those methods aren't included, but could be modified later.

r? @sfackler

Make vec::Drain and binary_heap::Drain covariant

add mir optimization tests, dump-mir-dir option

Auto merge of #34873 - alexcrichton:down-with-compiler-rt-for-good, r=brson

mk: Stop using cmake for compiler-rt

The compiler-rt build system has been a never ending cause of pain for Rust
unfortunately:

* The build system is very difficult to invoke and configure to only build
  compiler-rt, especially across platforms.
* The standard build system doesn't actually do what we want, not working for
  some of our platforms and requiring a significant number of patches on our end
  which are difficult to apply when updating compiler-rt.
* Compiling compiler-rt requires LLVM to be compiled, which... is a big
  dependency! This also means that over time compiler-rt is not guaranteed to
  build against older versions of LLVM (or newer versions), and we often want to
  work with multiple versions of LLVM simultaneously.

The makefiles and rustbuild already know how to compile C code, the code here is
far from the *only* C code we're compiling. This patch jettisons all logic to
work with compiler-rt's build system and just goes straight to the source. We
just list all files manually (copied from compiler-rt's
lib/builtins/CMakeLists.txt) and compile them into an archive.

It's likely that this means we'll fail to pick up new files when we upgrade
compiler-rt, but that seems like a much less significant cost to pay than what
we're currently paying.

cc #34400, first steps towards that

std: Fix usage of SOCK_CLOEXEC

This code path was intended to only get executed on Linux, but unfortunately the
`cfg!` was malformed so it actually never got executed.

core: impl From<T> for Option<T>

mk: Stop using cmake for compiler-rt

The compiler-rt build system has been a never ending cause of pain for Rust
unfortunately:

* The build system is very difficult to invoke and configure to only build
  compiler-rt, especially across platforms.
* The standard build system doesn't actually do what we want, not working for
  some of our platforms and requiring a significant number of patches on our end
  which are difficult to apply when updating compiler-rt.
* Compiling compiler-rt requires LLVM to be compiled, which... is a big
  dependency! This also means that over time compiler-rt is not guaranteed to
  build against older versions of LLVM (or newer versions), and we often want to
  work with multiple versions of LLVM simultaneously.

The makefiles and rustbuild already know how to compile C code, the code here is
far from the *only* C code we're compiling. This patch jettisons all logic to
work with compiler-rt's build system and just goes straight to the source. We
just list all files manually (copied from compiler-rt's
lib/builtins/CMakeLists.txt) and compile them into an archive.

It's likely that this means we'll fail to pick up new files when we upgrade
compiler-rt, but that seems like a much less significant cost to pay than what
we're currently paying.

cc #34400, first steps towards that

Auto merge of #34113 - srinivasreddy:deriving_rustfmt, r=brson

run rustfmt on libsyntax_ext/deriving folder

trans: Make base::internalize_symbols() respect explicit linkage directives.

Auto merge of #34694 - mathphreak:master, r=alexcrichton

Add IpAddr common methods

Per https://github.com/rust-lang/rfcs/pull/1668#issuecomment-230867962 no RFC is needed here.

The generated documentation for these methods is being weird. It shows a deprecation message referencing #27709 for each of them even though two of the referenced methods were stabilized as part of that issue. I don't know how best to address that.

Add doc for btree_map types

Auto merge of #33526 - steveklabnik:gh21889, r=alexcrichton

Add some warnings to std::env::current_exe

/cc #21889 @rust-lang/libs @semarie

I started writing this up. I'm not sure if we want to go into other things and in what depth; we don't currently have a lot of security-specific documentation to model after.

Thoughts?

Add the missing tracking issue field for #34931 to the receiver_try_iter stability attributes

Add doc examples for `Vec::{as_slice,as_mut_slice}`.

Introduced `NoDelim` and modified the compiler to support it.

Add regression test.

Support nested `macro_rules!`.

Auto merge of #34885 - GuillaumeGomez:btree_map_debug, r=alexcrichton

Add debug for btree_map::{Entry, VacantEntry, OccupiedEntry}

Run rustfmt on libsyntax_ext/deriving folder

re-work example

Rewrite/expand doc examples for `Vec::set_len`.

[CSS] Fix unwanted top margin for toggle wrapper

Auto merge of #34898 - sanxiyn:rollup, r=sanxiyn

Rollup of 5 pull requests

- Successful merges: #34807, #34853, #34875, #34884, #34889
- Failed merges:

Add codegen test to make sure that closures are 'internalized' properly.

Add debug for btree_map::{Entry, VacantEntry, OccupiedEntry}

Fix wrong condition in base::internalize_symbols().

Auto merge of #33974 - habnabit:eintr-retry-for-read-iterators, r=alexcrichton

Retry on EINTR in Bytes and Chars.

>Since Bytes and Chars called directly into Read::read, they didn't use any of the retrying wrappers. This allows both iterator types to retry.

mk: Remove -Wall -Werror everywhere

We're not writing C code, so there's not really much of a reason for us to get
warnings and errors from code we haven't written!

rustc: Remove soft-float from MIPS targets

Right now two MIPS targets in the compiler, `mips-unknown-linux-{gnu,musl}` both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the `-C soft-float` codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in #9617), and nowadays it's more appropriate to be done through a codegen
option.

This is motivated by #34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until #34841 landed because otherwise we would fail to compile C code as the
`-msoft-float` option wouldn't work.

Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.

If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!

Auto merge of #34879 - petrochenkov:fnptr, r=alexcrichton

Implement traits for variadic function pointers

Closes https://github.com/rust-lang/rust/issues/34874
cc https://github.com/rust-lang/rust/pull/28268

r? @alexcrichton

Auto merge of #34357 - tbu-:pr_exact_size_is_empty, r=brson

Add `is_empty` function to `ExactSizeIterator`

All other types implementing a `len` functions have `is_empty` already.

Auto merge of #34899 - michaelwoerister:always_internalize_symbols, r=eddyb

Run base::internalize_symbols() even for single-codegen-unit crates.

The initial linkage-assignment (especially for closures) is a conservative one that makes some symbols more visible than they need to be. While this is not a correctness problem, it does force the LLVM inliner to be more conservative too, which results in poor performance. Once translation is based solely on MIR, it will be easier to also make the initial linkage assignment a better fitting one. Until then `internalize_symbols()` does a good job of preventing most performance regressions.

This should solve the regressions reported in https://github.com/rust-lang/rust/issues/34891 and maybe also those in https://github.com/rust-lang/rust/issues/34831.

As a side-effect, this will also solve most of the problematic cases described in https://github.com/rust-lang/rust/issues/34793. Not reliably so, however. For that, we still need a solution like the one implement in https://github.com/rust-lang/rust/pull/34830.

cc @rust-lang/compiler

use a new feature name for String AddAssign

update the since field to 1.12.0 for String AddAssign

Fix doctest of `ExactSizeIterator::is_empty`

Run base::internalize_symbols() even for single-codegen-unit crates.

The initial linkage-assignment (especially for closures) is a conservative one that makes some symbols more visible than they need to be. While this is not a correctness problem, it does force the LLVM inliner to be more conservative too, which results in poor performance. Once translation is based solely on MIR, it will be easier to also make the initial linkage assignment a better fitting one. Until then `internalize_symbols()` does a good job of preventing most performance regressions.

Rollup merge of #34889 - infinity0:master, r=sanxiyn

Test fixes for ARM64

When these changes are applied, rustc 1.10.0 tests pass successfully on [asachi.debian.org](https://db.debian.org/machines.cgi?host=asachi).

Rollup merge of #34884 - shepmaster:from_raw_parts_doc, r=@nagisa

Improve {String,Vec}::from_raw_parts documentation

Rollup merge of #34875 - frewsxcv:std-slice-struct, r=GuillaumeGomez

Indicate where `std::slice` structs originate from.

None

Rollup merge of #34853 - frewsxcv:vec-truncate, r=GuillaumeGomez

Partial rewrite/expansion of `Vec::truncate` documentation.

None

Rollup merge of #34807 - sanxiyn:dump-mir, r=nagisa

Remove extra newlines in MIR dump

Add `librustc_driver::driver::reset_thread_local_state` and
remove the thread local state reset at the beginning of `phase_1_parse_input`.

Auto merge of #34886 - jseyfried:improve_stmt_matchers, r=eddyb

macros: fix bug in `stmt` matchers

Today, `stmt` matchers stop too early when parsing expression statements that begin with non-braced macro invocations. For example,
```rust
fn main() {
    macro_rules! m { ($s:stmt;) => { $s } }
    id!(vec![].push(0););
    //^ Before this PR, the `stmt` matcher only consumes "vec![]", so this is an error.
    //| After this PR, the `stmt` matcher consumes "vec![].push(0)", so this compiles.
}
```
This change is backwards compatible due to the follow set for `stmt`.

r? @eddyb

Remove rustdoc reference to `walk_dir`

Auto merge of #34860 - jseyfried:encapsulate_hygiene, r=nrc

Clean up and encapsulate `syntax::ext::mtwt`, rename `mtwt` to `hygiene`

r? @nrc

Add debug for hash_map::{Entry, VacantEntry, OccupiedEntry}

Remove extraneous words

Document from_raw_parts involves ownership transfer

implement AddAssign for String

Auto merge of #34876 - frewsxcv:vec-as-mut-slice, r=alexcrichton

Remove unnecessary indexing and deref in `Vec::as_mut_slice`.

None

doc/book: fix tests for non-x86 architectures, such as aarch64

`rustdoc --test` gets confused when "main" exists for some architectures but not others.

test: disable more stdcall tests for ARM arches. temp workaround for #24958

Remove some unit tests and that are redundant with `run-pass/hygiene.rs`
and that would be painful to rewrite.

Rename `mtwt` to `hygiene`

Clean up and encapsulate `syntax::ext::mtwt`

Add regression test

Auto merge of #34871 - petrochenkov:inherent, r=jseyfried

Do not resolve inherent static methods from other crates prematurely

Under some specific circumstances paths like `Type::method` can be resolved early in rustc_resolve instead of type checker. `Type` must be defined in another crate, it should be an enum or a trait object (i.e. a type that acts as a "module" in resolve), and `method` should be an inherent static method.
As a result, such paths don't go through `resolve_ufcs`, may be resolved incorrectly and break some invariants in type checker. This patch removes special treatment of such methods.

The removed code was introduced in https://github.com/rust-lang/rust/commit/2bd46e767c0fe5b6188df61cb9daf8f2e65a3ed0 to fix a problem that no longer exists.

r? @jseyfried

macros: Fix bug in statement matchers

Indicate where `std::slice` structs originate from.

Make .enumerate() example self-explanatory

Auto merge of #34829 - cgswords:tstream, r=nrc

Added tokenstream parser procedure

A tiny PR that simply adds a procedure for parsing `TokenStream`s to the parser in `src/libsyntax`. This is to ease using `TokenStream`s with the current (old) procedural macro system.

Implement traits for variadic function pointers

Auto merge of #34789 - jonathandturner:simplify_liberror, r=alexcrichton

Simplify librustc_errors

This is part 2 of the error crate refactor, starting with #34403.

In this refactor, I focused on slimming down the error crate to fewer moving parts.  As such, I've removed quite a few parts and replaced the with simpler, straight-line code.  Specifically, this PR:

* Removes BasicEmitter
* Remove emit from emitter, leaving emit_struct
* Renames emit_struct to emit
* Removes CoreEmitter and focuses on a single Emitter
* Implements the latest changes to error format RFC (#1644)
* Removes (now-unused) code in emitter.rs and snippet.rs
* Moves more tests to the UI tester, removing some duplicate tests in the process

There is probably more that could be done with some additional refactoring, but this felt like it was getting to a good state.

r? @alexcrichton   cc: @Manishearth (as there may be breaking changes in stuff I removed/changed)

Auto merge of #34606 - mathstuf:llvm-with-ninja, r=alexcrichton

llvm, rt: build using the Ninja generator if available

The Ninja generator generally builds much faster than make. It may also
be used on Windows to have a vast speed improvement over the Visual
Studio generators.

Currently hidden behind an `--enable-ninja` flag because it does not
obey the top-level `-j` or `-l` flags given to `make`.

Remove unnecessary indexing and deref in `Vec::as_mut_slice`.

Add examples for LinkedList