rollup merge of #20231: fhahn/issue-20226-eexist

I've created a patch for #20226, which maps `EEXIST` to the `PathAlreadyExists` error on Unix. To test this, I use `mkdir`, which raises `EEXIST` if the directory already exists.

On Windows, I map `ERROR_ALREADY_EXISTS` to `PathAlreadyExist`, but I am note sure if `mkdir` on Windows raises `ERROR_ALREADY_EXISTS` and do not have a Windows installation handy for testing.

And I noticed another thing. No error seems to map to `IoErrorKind::PathDoesntExist` and I am wondering what the difference to `FileNotFound` is?

rollup merge of #20230: bheesham/noshard

I forgot to do this in my previous PR. This should close #19145 .

rollup merge of #20223: aochagavia/typo

rollup merge of #20216: sfackler/fix-mangling

Closes #20209

r? @alexcrichton

rollup merge of #20215: csouth3/hashmap-rename

Rename struct `Entries` to `Iter` in hash/table.rs and hash/map.rs, to match the naming convention of rust-lang/rfcs#344.

This is a [breaking-change].

rollup merge of #20214: bluss/fix-hashmap-example

The example derived Hash + Eq on a type that was used as *values* for
a hashmap.. for the example to make sense, we have to use a custom *key*
type.

Write a slightly more involved example, still using Vikings, but this
time as key.

I preferred using String over &str here, since that's the typical usage
and we might want to lead users down that path.

rollup merge of #20210: tshepang/patch-5

rollup merge of #20207: jroesch/issue-18906-testcase

Closes issue #18906. This is what we talked about last night/early this morning. r? @nikomatsakis.

rollup merge of #20205: tshepang/patch-4

The paragraph following this removed one has the same info, only better.

rollup merge of #20195: nagisa/unused-typo

rollup merge of #20194: nick29581/dst-syntax

Part of #19607.

r? @nikomatsakis

rollup merge of #20191: lifthrasiir/double-debug_assert

Yes, really. That definition wouldn't work anyway.

This also fixes repeated entries for `debug_assert!` from libcore docs. Maybe we should warn such macro definitions in the first place?

rollup merge of #20182: brianloveswords/patch-2

Treemap should be BTreeMap

rollup merge of #20165: tamird/needstest-tests

@alexcrichton @jakub-

rollup merge of #20160: nick29581/ranges2

The first six commits are from an earlier PR (#19858) and have already been reviewed. This PR makes an awful hack in the compiler to accommodate slices both natively and in the index a range form. After a snapshot we can hopefully add the new Index impls and then we can remove these awful hacks.

r? @nikomatsakis (or anyone who knows the compiler, really)

rollup merge of #20042: alexcrichton/second-pass-ptr

This commit performs a second pass for stabilization over the `std::ptr` module.
The specific actions taken were:

* The `RawPtr` trait was renamed to `PtrExt`
* The `RawMutPtr` trait was renamed to `PtrMutExt`
* The module name `ptr` is now stable.
* These functions were all marked `#[stable]` with no modification:
  * `null`
  * `null_mut`
  * `swap`
  * `replace`
  * `read`
  * `write`
  * `PtrExt::is_null`
  * `PtrExt::is_not_null`
  * `PtrExt::offset`
* These functions remain unstable:
  * `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive
                         as null isn't the only bad value, and it's unclear
                         whether we want to commit to these functions at this
                         time. The reference/lifetime semantics as written are
                         also problematic in how they encourage arbitrary
                         lifetimes.
  * `zero_memory` - This function is currently not used at all in the
                    distribution, and in general it plays a broader role in the
                    "working with unsafe pointers" story. This story is not yet
                    fully developed, so at this time the function remains
                    unstable for now.
  * `read_and_zero` - This function remains unstable for largely the same
                      reasons as `zero_memory`.
* These functions are now all deprecated:
  * `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead.
  * `PtrExt::to_uint` - use an `as` expression instead.

rollup merge of #19661: alexcrichton/mutex-result

All of the current std::sync primitives have poisoning enable which means that
when a task fails inside of a write-access lock then all future attempts to
acquire the lock will fail. This strategy ensures that stale data whose
invariants are possibly not upheld are never viewed by other tasks to help
propagate unexpected panics (bugs in a program) among tasks.

Currently there is no way to test whether a mutex or rwlock is poisoned. One
method would be to duplicate all the methods with a sister foo_catch function,
for example. This pattern is, however, against our [error guidelines][errors].
As a result, this commit exposes the fact that a task has failed internally
through the return value of a `Result`.

[errors]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants

All methods now return a `LockResult<T>` or a `TryLockResult<T>` which
communicates whether the lock was poisoned or not. In a `LockResult`, both the
`Ok` and `Err` variants contains the `MutexGuard<T>` that is being returned in
order to allow access to the data if poisoning is not desired. This also means
that the lock is *always* held upon returning from `.lock()`.

A new type, `PoisonError`, was added with one method `into_guard` which can
consume the assertion that a lock is poisoned to gain access to the underlying
data.

This is a breaking change because the signatures of these methods have changed,
often incompatible ways. One major difference is that the `wait` methods on a
condition variable now consume the guard and return it in as a `LockResult` to
indicate whether the lock was poisoned while waiting. Most code can be updated
by calling `.unwrap()` on the return value of `.lock()`.

[breaking-change]

rollup merge of #19457: reem/remove-is-lang-item

Removes a FIXME on closed issue #15064. This flag is no
longer needed or used since reflection is gone.

Rebasing and reviewer changes

Fallout from mut slices

Remove ExprSlice by hacking the compiler

[breaking-change]

The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.

Add hypothetical support for ranges with only an upper bound

Note that this doesn't add the surface syntax.

std: Second pass stabilization for `ptr`

This commit performs a second pass for stabilization over the `std::ptr` module.
The specific actions taken were:

* The `RawPtr` trait was renamed to `PtrExt`
* The `RawMutPtr` trait was renamed to `MutPtrExt`
* The module name `ptr` is now stable.
* These functions were all marked `#[stable]` with no modification:
  * `null`
  * `null_mut`
  * `swap`
  * `replace`
  * `read`
  * `write`
  * `PtrExt::is_null`
  * `PtrExt::offset`
* These functions remain unstable:
  * `as_ref`, `as_mut` - the return value of an `Option` is not fully expressive
                         as null isn't the only bad value, and it's unclear
                         whether we want to commit to these functions at this
                         time. The reference/lifetime semantics as written are
                         also problematic in how they encourage arbitrary
                         lifetimes.
  * `zero_memory` - This function is currently not used at all in the
                    distribution, and in general it plays a broader role in the
                    "working with unsafe pointers" story. This story is not yet
                    fully developed, so at this time the function remains
                    unstable for now.
  * `read_and_zero` - This function remains unstable for largely the same
                      reasons as `zero_memory`.
* These functions are now all deprecated:
  * `PtrExt::null` - call `ptr::null` or `ptr::null_mut` instead.
  * `PtrExt::to_uint` - use an `as` expression instead.
  * `PtrExt::is_not_null` - use `!p.is_null()` instead.

std: Stabilization pass for mutex/rwlock/condvar

This commit performs a stabilization pass over the sync::{mutex, rwlock,
condvar} modules, marking the following items as stable:

* Mutex
* Mutex::new
* Mutex::lock
* Mutex::try_lock
* MutexGuard
* RWLock
* RWLock::new
* RWLock::read
* RWLock::try_read
* RWLock::write
* RWLock::try_write
* RWLockReadGuard
* RWLockWriteGuard
* Condvar
* Condvar::new
* Condvar::wait
* Condvar::notify_one
* Condvar::notify_all
* PoisonError
* TryLockError
* TryLockError::Poisoned
* TryLockError::WouldBlock
* LockResult
* TryLockResult

The following items remain unstable to explore future possibilities of unifying
the static/non-static variants of the types:

* StaticMutex
* StaticMutex::new
* StaticMutex::lock
* StaticMutex::try_lock
* StaticMutex::desroy
* StaticRWLock
* StaticRWLock::new
* StaticRWLock::read
* StaticRWLock::try_read
* StaticRWLock::write
* StaticRWLock::try_write
* StaticRWLock::destroy

The following items were removed in favor of `Guard<'static, ()>` instead.

* StaticMutexGuard
* StaticRWLockReadGuard
* StaticRWLockWriteGuard

auto merge of #20101 : alexcrichton/rust/issue-20096, r=aturon

These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.

Closes #20096

auto merge of #20058 : Kimundi/rust/str_pattern_pre, r=alexcrichton

This stabilizes most methods on `&str` working with patterns in a way that is forwards-compatible with a generic string pattern matching API:
- Methods that are using the primary name for their operation are marked as `#[stable]`, as they can be upgraded to a full `Pattern` API later without existing code breaking. Example: `contains(&str)`
- Methods that are using a more specific name in order to not clash with the primary one are marked as `#[unstable]`, as they will likely be removed once their functionality is merged into the primary one. Example: `contains_char<C: CharEq>(C)`
- The method docs got changed to consistently refer to the pattern types as a pattern.
- Methods whose names do not match in the context of the more generic API got renamed. Example: `trim_chars -> trim_matches`

Additionally, all methods returning iterators got changed to return unique new types with changed names in accordance with the new naming guidelines.

See also https://github.com/rust-lang/rfcs/pull/528

Due to some deprecations and type changes, this is a

[breaking-change]

std: Return Result from RWLock/Mutex methods

All of the current std::sync primitives have poisoning enable which means that
when a task fails inside of a write-access lock then all future attempts to
acquire the lock will fail. This strategy ensures that stale data whose
invariants are possibly not upheld are never viewed by other tasks to help
propagate unexpected panics (bugs in a program) among tasks.

Currently there is no way to test whether a mutex or rwlock is poisoned. One
method would be to duplicate all the methods with a sister foo_catch function,
for example. This pattern is, however, against our [error guidelines][errors].
As a result, this commit exposes the fact that a task has failed internally
through the return value of a `Result`.

[errors]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants

All methods now return a `LockResult<T>` or a `TryLockResult<T>` which
communicates whether the lock was poisoned or not. In a `LockResult`, both the
`Ok` and `Err` variants contains the `MutexGuard<T>` that is being returned in
order to allow access to the data if poisoning is not desired. This also means
that the lock is *always* held upon returning from `.lock()`.

A new type, `PoisonError`, was added with one method `into_guard` which can
consume the assertion that a lock is poisoned to gain access to the underlying
data.

This is a breaking change because the signatures of these methods have changed,
often incompatible ways. One major difference is that the `wait` methods on a
condition variable now consume the guard and return it in as a `LockResult` to
indicate whether the lock was poisoned while waiting. Most code can be updated
by calling `.unwrap()` on the return value of `.lock()`.

[breaking-change]

auto merge of #19549 : huonw/rust/middle-ty-2, r=nikomatsakis

This takes building `librustc/lib.rs` from using 696 MB to 588 (`rustc --no-trans`), and 1.99 GB to 1.87 (`rustc -O`). It also reduces `sty` down to 32 bytes on platforms with 64-bit pointers, at the expense of some more side-tables in `ctxt`. I'm sure there's more gains to be had from reducing the size of the side tables (e.g. by making the actual things they're storing smaller).

r? @nikomatsakis

More rebase fixes.

Update rustc_driver tests.

Rebase fixes.

I've totally mangled the history with these rebases; sorry, future programmer!

Add the -Z print-enum-sizes flag for displaying enum info.

This replaces required the RUST_LOG=... invocation to make it much more
user friendly.

Fix rebase artifacts.

Slash the ast::Stmt type from 104 to 24 bytes.

(on platforms with 64-bit pointers.)

The StmtMac variant is rather large and also fairly rare, so let's
optimise the common case.

Print info from the barefn and region interners in the tcx.

Intern Region in tcx.

This makes sty only 32 bytes on machines with 64-bit pointers.

Collect tcx arenas into a single struct.

This allows expanding how many arenas exist without users having to
care, since they are all created with CtxtArena::new().

Intern BareFnTys to make sty slightly smaller.

This cuts the ty_bare_fn variant to 48 bytes rather than 56. There
doesn't seem to be a noticable memory usage decrease from this.

Switch Region information from uint to u32.

This reduces memory use for building librustc with -O from 1.88 to 1.76
GB.

Intern substs before storing them in the tcx.

This cuts memory use dramatically from the previous commit, and reduces
use overall. E.g. the memory usage of `rustc -O librustc/lib.rs` seems
to drop 100MB from 1.98GB to 1.88GB (on one run anyway).

Store Substs in an arena in the tcx.

This current inflates memory use more than 3 times.

Implement debug printing for tcx interner sty's.

auto merge of #19765 : luqmana/rust/nonzero-lang-item, r=nikomatsakis

This extends the nullable enum opt to traverse beyond just the first level to find possible fields to use as the discriminant. So now, it'll work through structs, tuples, and fixed sized arrays. This also introduces a new lang item, NonZero, that you can use to wrap raw pointers or integral types to indicate to rustc that the underlying value is known to never be 0/NULL. We then use this in Vec, Rc and Arc to have them also benefit from the nullable enum opt.

As per https://github.com/rust-lang/rfcs/pull/499 NonZero is not exposed via the `libstd` facade.

```
x86_64 Linux:
                        T       Option<T> (Before)      Option<T> (After)
----------------------------------------------------------------------------------
Vec<int>                24          32                      24
String                  24          32                      24
Rc<int>                 8           16                      8
Arc<int>                8           16                      8
[Box<int>, ..2]         16          24                      16
(String, uint)          32          40                      32
```

Fixes #19419.
Fixes #13194.
Fixes #9378.
Fixes #7576.

Marked find and rfind as stable

auto merge of #19227 : johshoff/rust/master, r=brson

Using the current directory may not always be appropriate, for example in
the case where it will unnecessarily trigger a backup to be made.

The only risk with this change is that systems might not have a mktemp.
I am not aware of such a system, but have not tested on Windows. It is
working on a basic Ubuntu and OS X installation.

libcollections: impl Send/Sync for Vec.

libcoretest: Add tests for NonZero.

libcore: Use Zeroable trait to try to limit what types may be used with NonZero.

librustc_trans: Get rid of unnecessary allocation in finding discriminant field.

libcore: Don't impl RawPtr* traits for NonZero.

Don't expose NonZero through libstd.

Add tests for NonZero.

libcore: Make it unsafe to create NonZero and impl Deref.

liballoc: Use NonZero in Arc.

liballoc: Use NonZero in Rc.

libcollections: Use NonZero in Vec.

libcore: Add NonZero lang item and implement some methods.

librustc: Add NonZero lang item and use it if possible for nullable pointer enum opt.

Add tests.

librustc: Try looking in fixed sized arrays for nullable enum opt.

librustc: Try looking in tuple fields for nullable enum opt.

librustc: Traverse arbitrarily deep for nullable enum opt.

Regression test for #17740

Closes #17740.

Regression test for #17728

Closes #17728.

Regression test for #16538

Closes #16538.

mk: Stop generating docs for deprecated crates

These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.

Closes #20096

Regression test for #15034

Closes #15034.

Regression test for #14227

Closes #14227.

Regression test for #14386

Closes #14386.

Regression tests for #13853

Closes #13853, #14889.

Regression test for #13808

Closes #13808.

Regression test for #13665

Closes #13665.

Regression test for #13655

Closes #13655.

Regression test for simple case of #9197

Regression test for #8874

Closes #8874.

Update test for #5543

Closes #5543.

Regression test for #3902

Closes #3902.

auto merge of #20185 : csouth3/rust/dlist-deprecate, r=alexcrichton

This PR deprecates the `DList::ListInsertion` trait, in accordance with rust-lang/rfcs#509.  The functions which were previously part of the ListInsertion impl for `DList::IterMut` have been moved to be inherent methods on the iterator itself, and appropriate doctests have been added.

Split overly long line

auto merge of #20136 : eddyb/rust/format-args, r=alexcrichton

We have the technology: no longer do you need to write closures to use `format_args!`.
This is a `[breaking-change]`, as it forces you to clean up old hacks - if you had code like this:
```rust
format_args!(fmt::format, "{} {} {}", a, b, c)
format_args!(|args| { w.write_fmt(args) }, "{} {} {}", x, y, z)
```
change it to this:
```rust
fmt::format(format_args!("{} {} {}", a, b, c))
w.write_fmt(format_args!("{} {} {}", x, y, z))
```
To allow them to be called with `format_args!(...)` directly, several functions were modified to
take `fmt::Arguments` by value instead of by reference. Also, `fmt::Arguments` derives `Copy`
now in order to preserve all usecases that were previously possible.

Fallout of changing format_args!(f, args) to f(format_args!(args)).

syntax: change format_args! to produce fmt::Arguments instead of calling a function with them.

syntax: use std::string::String unqualified in format.

syntax: turn the match-call generated by format_args inside-out.

syntax: format: put static arrays in their own blocks to avoid needing a wrapper block.

syntax: format: remove unused method_statics field.

auto merge of #19916 : SimonSapin/rust/ascii-reform, r=sfackler

Implements [RFC 486](https://github.com/rust-lang/rfcs/pull/486). Fixes #19908.

* Rename `to_ascii_{lower,upper}` to `to_ascii_{lower,upper}case`, per #14401
* Remove the `Ascii` type and associated traits: `AsciiCast`, `OwnedAsciiCast`, `AsciiStr`, `IntoBytes`, and `IntoString`.
* As a replacement, add `.is_ascii()` to `AsciiExt`, and implement `AsciiExt` for `u8` and `char`.

[breaking-change]

auto merge of #20244 : japaric/rust/bc-no-move, r=nikomatsakis

closes #19141
closes #20193
closes #20228

---

Currently whenever we encounter `let f = || {/* */}`, we *always* type check the RHS as a *boxed* closure. This is wrong when the RHS is `move || {/* */}` (because boxed closures can't capture by value) and generates all sort of badness during trans (see issues above). What we *should* do is always type check `move || {/* */}` as an *unboxed* closure, but ~~I *think* (haven't tried)~~ (2) this is not feasible right now because we have a limited form of kind (`Fn` vs `FnMut` vs `FnOnce`) inference that only works when there is an expected type (1).

In this PR, I've chosen to generate a type error whenever `let f = move || {/* */}` is encountered. The error asks the user to annotate the kind of the unboxed closure (e.g. `move |:| {/* */}`). Once annotated, the compiler will type check the RHS as an unboxed closure which is what the user wants.

r? @nikomatsakis

(1) AIUI it only triggers in this scenario:

``` rust
fn is_uc<F>(_: F) where F: FnOnce() {}

fn main() {
    is_uc(|| {});  // type checked as unboxed closure with kind `FnOnce`
}
```

(2) I checked, and it's not possible because `check_unboxed_closure` expects a `kind` argument, but we can't supply that argument in this case (i.e. `let f = || {}`, what's the kind?). We could force the `FnOnce` kind in that case, but that's ad hoc. We should try to infer the kind depending on how the closure is used afterwards, but there is no inference mechanism to do that (at least, not right now).

auto merge of #20119 : FlaPer87/rust/oibit-send-and-friends, r=nikomatsakis

More work on opt-in built in traits. `Send` and `Sync` are not opt-in, `OwnedPtr` renamed to `UniquePtr` and the `Send` and `Sync` traits are now unsafe.

NOTE: This likely needs to be rebased on top of the yet-to-land snapshot.

r? @nikomatsakis

cc #13231

Make trait's impls consistent for unix/windows

Implement Sync/Send for windows' UnixStream

auto merge of #20238 : barosl/rust/regex-repeater-panic, r=huonw

This bug has also affected the `regex!` macro, which has caused an ICE when such an invalid expression is provided.

Fixes #20208.

auto merge of #20158 : nikomatsakis/rust/fn-inference-refactor, r=eddyb

Various refactorings simplifying the mem-categorization and regionck interface. This is working towards an improvement for closure-and-upvar-mode inference.

r? @eddyb

auto merge of #20143 : csouth3/rust/vecmap-reserve, r=Gankro

Implement `reserve_len` and `reserve_len_exact` for `VecMap` in accordance with rust-lang/rfcs#509.

auto merge of #19254 : nick29581/rust/dxr-glob, r=pcwalton

There is also some work here to make resolve a bit more stable - it no longer overwrites a specific import with a glob import.

r?

Rebasing changes

Implement Sync/Send for windows TCP types

auto merge of #20133 : apasel422/rust/binary_heap, r=alexcrichton

Some more tidying up.

Fix fallout

save-analysis: emit names of items that a glob import actually imports.

There is also some work here to make resolve a bit more stable - it no longer overwrites a specific import with a glob import.

[breaking-change]

Import shadowing of single/list imports by globs is now forbidden. An interesting case is where a glob import imports a re-export (`pub use`) of a single import. This still counts as a single import for the purposes of shadowing .You can usually fix any bustage by re-ordering such imports. A single import may still shadow (override) a glob import or the prelude.