Add "-" shortcut

Auto merge of #45822 - kennytm:rollup, r=kennytm

Rollup of 9 pull requests

- Successful merges: #45470, #45588, #45682, #45714, #45751, #45764, #45778, #45782, #45784
- Failed merges:

Rollup merge of #45784 - harpocrates:fix/print-parens-cast-lt, r=kennytm

Pretty print parens around casts on the LHS of `<`/`<<`

When pretty printing a cast expression occuring on the LHS of a `<` or `<<` expression, we should add parens around the cast. Otherwise, the `<`/`<<` gets interpreted as the beginning of the generics for the type on the RHS of the cast.

Consider:

    $ cat parens_cast.rs
    macro_rules! negative {
        ($e:expr) => { $e < 0 }
    }

    fn main() {
        negative!(1 as i32);
    }

Before this PR, the output of the following is not valid Rust:

    $ rustc -Z unstable-options --pretty=expanded parens_cast.rs
    #![feature(prelude_import)]
    #![no_std]
    #[prelude_import]
    use std::prelude::v1::*;
    #[macro_use]
    extern crate std as std;
    macro_rules! negative(( $ e : expr ) => { $ e < 0 });

    fn main() { 1 as i32 < 0; }

After this PR, the output of the following is valid Rust:

    $ rustc -Z unstable-options --pretty=expanded parens_cast.rs
    #![feature(prelude_import)]
    #![no_std]
    #[prelude_import]
    use std::prelude::v1::*;
    #[macro_use]
    extern crate std as std;
    macro_rules! negative(( $ e : expr ) => { $ e < 0 });

    fn main() { (1 as i32) < 0; }

I've gone through several README/wiki style documents but I'm still not sure where to test this though. I'm not even sure if this sort of thing is tested...

Rollup merge of #45782 - frewsxcv:frewsxcv-shorthands-helpers, r=manishearth

Display all emission types in error msg if user inputs invalid option.

before:

```
> rustc --emit foo
error: unknown emission type: `foo`
```

after:

```
> rustc --emit foo
error: unknown emission type: `foo` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info`
```

Rollup merge of #45778 - Havvy:patch-1, r=steveklabnik

Update reference link in doc's 404

It's currently linking to a page that says it's on the page I'm changing the link too.

Rollup merge of #45764 - QuietMisdreavus:rustdoc-doctest-lints, r=GuillaumeGomez

rustdoc: add #[allow(unused)] to every doctest

More information in #45750 - this is behavior that was documented but not actually implemented.

I also reordered how outer attributes are applied to doctests. Previously, attributes from `#![doc(test(attr(...)))]` would be applied *after* attributes from within the test itself, meaning if a doctest tried to override lints that would be set crate-wide, it wouldn't work at all. This gives a better scope of how lints can be applied.

Closes #45750

Rollup merge of #45751 - estebank:issue-44684, r=nikomatsakis

Handle anon lifetime arg being returned with named lifetime return type

When there's a lifetime mismatch between an argument with an anonymous
lifetime being returned in a method with a return type that has a named
lifetime, show specialized lifetime error pointing at argument with a
hint to give it an explicit lifetime matching the return type.

```
error[E0621]: explicit lifetime required in the type of `other`
  --> file2.rs:21:21
   |
17 |     fn bar(&self, other: Foo) -> Foo<'a> {
   |                   ----- consider changing the type of `other` to `Foo<'a>`
...
21 |                     other
   |                     ^^^^^ lifetime `'a` required
```

Follow up to #44124 and #42669. Fix #44684.

Rollup merge of #45714 - sdroege:thread-panic-docs, r=dtolnay

Update the std::thread docs and clarify that panics can nowadays be caught

Rollup merge of #45682 - RalfJung:rwlock-guards, r=alexcrichton

RwLock guards are Sync if T is

Currently, the compiler requires `T` to also be `Send`.  There is no reason for
that.  `&Rw{Read,Write}LockGuard` only provides a shared referenced to `T`, sending
that across threads is safe if `T` is `Sync`.

Cc @oconnor663

Rollup merge of #45588 - Keruspe:master, r=alexcrichton

rustbuild: don't try to install rls if ToolState is not Testing

We already do that for the Dist Step so we would end up trying to install something that we didn't dist.

Rollup merge of #45470 - GuillaumeGomez:unix-metadata-ext, r=QuietMisdreavus

add missing docs for MetadataExt

r? @rust-lang/docs

Auto merge of #45666 - Amanieu:tls-model, r=alexcrichton

Allow overriding the TLS model

This PR adds the ability to override the default "global-dynamic" TLS model with a more specific one through a target json option or a command-line option. This allows for better code generation in certain situations.

This is similar to the `-ftls-model=` option in GCC and Clang.

Auto merge of #45620 - ollie27:rustdoc_impl_generic_dupe, r=QuietMisdreavus

rustdoc: Fix duplicated impls with generics

The same type can appear multiple times in impls so we need to use a set
to avoid adding it multiple times.

Fixes: #45584

Update comments in cast-lt.pp

review comments

Auto merge of #45571 - zackmdavis:regenerate_char_private, r=alexcrichton

regenerate libcore/char_private.rs

(filed separately from the work in #45569, because of this matter of the updated Unicode data; see also #45567)

char_private.rs is generated programmatically by char_private.py, using data retrieved from the Unicode Consortium's website.

The motivation here was to make `is_printable` crate-visible (with `pub(crate)`), but it would seem that the Unicode data has changed slightly since char_private.rs was last generated.

Display all emission types in error msg if user inputs invalid option.

before:

```
> rustc --emit foo
error: unknown emission type: `foo`
```

after:

```
> rustc --emit foo
error: unknown emission type: `foo` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info`
```

Auto merge of #45668 - nikomatsakis:nll-free-region, r=arielb1

extend NLL with preliminary support for free regions on functions

This PR extends https://github.com/rust-lang/rust/pull/45538 with support for free regions. This is pretty preliminary and will no doubt want to change in various ways, particularly as we add support for closures, but it's enough to get the basic idea in place:

- We now create specific regions to represent each named lifetime declared on the function.
- Region values can contain references to these regions (represented for now as a `BTreeSet<RegionIndex>`).
- If we wind up trying to infer that `'a: 'b` must hold, but no such relationship was declared, we report an error.

It also does a number of drive-by refactorings.

r? @arielb1

cc @spastorino

Move tls-model to a -Z option since it is unstable

Auto merge of #45811 - DSpeckhals:update-rustfmt-rls, r=nikomatsakis

tools: Fix rustfmt and the RLS

These tools have been corrected in their upstream repo's, and the submodules have been updated here to reflect that. I also had to update Cargo to match what the RLS is expecting.

The tool states for `rustfmt` and `rls` where both changed from "Broken" to "Testing" in this commit, thus enabling testing and distribution again.

Auto merge of #45322 - infinity0:master, r=alexcrichton

When cross-compiling, also build target-arch tarballs for libstd. (Closes: #42320)

Half of the logic is actually in there already in install.rs:install_std but it fails with an error like:

sh: 0: Can't open /<<BUILDDIR>>/rustc-1.21.0+dfsg1/build/tmp/dist/rust-std-1.21.0-powerpc64le-unknown-linux-gnu/install.sh

because the target-arch dist tarball wasn't built as well. This commit fixes that so the overall install works.

There is one minor bug in the existing code which this commit doesn't fix - the install.log from multiple runs of the installer gets clobbered, which seems like it might interfere with the uninstall process (I didn't look very deeply into this, because it doesn't affect what I need to do.) The actual installed files under DESTDIR seem fine though - either they are installed under an arch-specific path, or the multiple runs will clobber the same path with the same arch-independent file.

tools: Fix rustfmt and the RLS

These tools have been corrected in their upstream repo's, and the
submodules have been updated here to reflect that. I also had to update
Cargo to match what the RLS is expecting.

The tool states for `rustfmt` and `rls` where both changed from "Broken"
to "Testing" in this commit, thus enabling testing and distribution
again.

Auto merge of #45369 - fintelia:patch-1, r=BurntSushi

Implement is_empty() for BufReader

Simple implementation of `is_empty` method for BufReader so it is possible to tell whether there is any data in its buffer.

I didn't know correct stability annotation to place on the function. Presumably there is no reason to place this feature behind a feature flag, but I wasn't sure how to tag it as an unstable feature without that.

CC: #45323

Auto merge of #45737 - oli-obk:json, r=petrochenkov

Pretty print json in ui tests

I found the json output in one line to not be useful for reviewing

r? @petrochenkov

Ensure dist::Std for every libstd target. (Closes: #42320)

This fixes cross-compile installation. Half of the logic is actually in there
already in install.rs:install_std but it fails with an error like:

sh: 0: Can't open /<<BUILDDIR>>/rustc-1.21.0+dfsg1/build/tmp/dist/rust-std-1.21.0-powerpc64le-unknown-linux-gnu/install.sh

because the target-arch dist tarball wasn't built as well.

Adjust json errors to byte changes

Auto merge of #45798 - nrc:rls-bugs-3, r=eddyb

A couple more save-analysis fixes

r? @eddyb

Auto merge of #45758 - nzig:explain-span-ctxt, r=petrochenkov

Add comment explaining the ctxt field in Span

As discussed in #45747.

r? @petrochenkov

Fix comments

save-analysis: fix bugs in method chains

Use the span we save in the PathSegment for a method call, rather than searching for it in the text.

Fixes https://github.com/nrc/rls-analysis/issues/111

Auto merge of #45756 - topecongiro:fix-typos/librustc_typeck, r=kennytm

Fix typos in README.md

This nitpicky PR fixes few typos I found while reading `README.md`s.

save-analysis: give better info for Unions

Auto merge of #45770 - spastorino:newtype_index, r=nikomatsakis

Make last structs indexes definitions use newtype_index macro

This PR makes the last two index structs not using newtype_index macro to use it and also fixes this https://github.com/rust-lang/rust/issues/45763 issue.

Added tests

Auto merge of #45723 - sinkuu:ice_45493, r=arielb1

Fix MIR inlining panic in generic function

MIR inlining calls `Instance::resolve` with a substs containing param, and `trans_apply_param_substs` panics. ~~This PR fixes it by making `Instance::resolve` return `None` if `substs.has_param_types()`, though I'm not sure if this is a right fix.~~

Fixes #45493.

Handle anon lifetime arg being returned with named lifetime return type

When there's a lifetime mismatch between an argument with an anonymous
lifetime being returned in a method with a return type that has a named
lifetime, show specialized lifetime error pointing at argument with a
hint to give it an explicit lifetime matching the return type.

```
error[E0621]: explicit lifetime required in the type of `other`
  --> file2.rs:21:21
   |
17 |     fn bar(&self, other: Foo) -> Foo<'a> {
   |                   ----- consider changing the type of `other` to `Foo<'a>`
...
21 |                     other
   |                     ^^^^^ lifetime `'a` required
```

Follow up to #44124 and #42669.

Pretty print parens around casts on the LHS of '<'

When pretty printing a cast expression occuring on the LHS of a '<'
or '<<' expression, we should add parens around the cast. Otherwise,
the '<'/'<<' gets interpreted as the beginning of the generics for
the type on the RHS of the cast.

Auto merge of #45072 - nikomatsakis:issue-38714, r=arielb1

new rules for merging expected and supplied types in closure signatures

As uncovered in #38714, we currently have some pretty bogus code for combining the "expected signature" of a closure with the "supplied signature". To set the scene, consider a case like this:

```rust
fn foo<F>(f: F)
where
  F: for<'a> FnOnce(&'a u32) -> &'a u32
  // ^ *expected* signature comes from this where-clause
{
    ...
}

fn main() {
    foo(|x: &u32| -> &u32 { .. }
     // ^^^^^^^^^^^^^^^^^ supplied signature
     // comes from here
}
```

In this case, the supplied signature (a) includes all the parts and (b) is the same as the expected signature, modulo the names used for the regions. But often people supply only *some* parts of the signature. For example, one might write `foo(|x| ..)`, leaving *everything* to be inferred, or perhaps `foo(|x: &u32| ...)`, which leaves the return type to be inferred.

In the current code, we use the expected type to supply the types that are not given, but otherwise use the type the user gave, except for one case: if the user writes `fn foo(|x: _| ..)` (i.e., an underscore at the outermost level), then we will take the expected type (rather than instantiating a fresh type variable). This can result in nonsensical situations, particularly with bound regions that link the types of parameters to one another or to the return type. Consider `foo(|x: &u32| ...)` -- if we *literally* splice the expected return type of `&'a u32` together with what the user gave, we wind up with a signature like `for<'a> fn(&u32) -> &'a u32`. This is not even permitted as a type, because bound regions like `'a` must appear also in the arguments somewhere, which is why #38714 leads to an ICE.

This PR institutes some new rules. These are not meant to be the *final* set of rules, but they are a kind of "lower bar" for what kind of code we accept (i.e., we can extend these rules in the future to be smarter in some cases, but -- as we will see -- these rules do accept some things that we then would not be able to back off from).

These rules are derived from a few premises:

- First and foremost, anonymous regions in closure annotation are mostly requests for the code to "figure out the right lifetime" and shouldn't be read too closely. So for example when people write a closure signature like `|x: &u32|`, they are really intended for us to "figure out" the right region for `x`.
    - In contrast, the current code treats this supplied type as being more definitive. In particular, writing `|x: &u32|` would always result in the region of `x` being bound in the closure type. In other words, the signature would be something like `for<'a> fn(&'a u32)` -- this is derived from the fact that `fn(&u32)` expands to a type where the region is bound in the fn type.
    - This PR takes a different approach. The "binding level" for reference types appearing in closure signatures can be informed in some cases by the expected signature. So, for example, if the expected signature is something like `(&'f u32)`, where the region of the first argument appears free, then for `|x: &u32|`, the new code would infer `x` to also have the free region `'f`.
        - This inference has some limits. We don't do this for bindings that appear within the selected types themselves. So e.g. `|x: fn(&u32)|`, when combined with an expected type of `fn(fn(&'f u32))`, would still result in a closure that expects `for<'a> fn(&'a u32)`. Such an annotation will ultimately result in an error, as it happens, since `foo` is supplying a `fn(&'f u32)` to the closure, but the closure signature demands a `for<'a> fn(&'a u32)`. But still we choose to trust it and have the user change it.
        - I wanted to preserve the rough intuition that one can copy-and-paste a type out of the fn signature and into the fn body without dramatically changing its meaning. Interestingly, if one has `|x: &u32|`, then regardless of whether the region of `x` is bound or free in the closure signature, it is also free in the region body, and that is also true when one writes `let x: &u32`, so that intuition holds here. But the same would not be true for `fn(&u32)`, hence the different behavior.
- Second, we must take either **all** the references to bound regions from the expected type or **none**. The current code, as we saw, will happily take a bound region in the return type but drop the other place where it is used, in the parameters. Since bound regions are all about linking multiple things together, I think it's important not to do that. (That said, we could conceivably be a bit less strict here, since the subtyping rules will get our back, but we definitely don't want any bound regions that appear only in the return type.)
- Finally, we cannot take the bound region names from the supplied types and "intermix" them with the names from the expected types.
    - We *could* potentially do some alpha renaming, but I didn't do that.
- Ultimately, if the types the user supplied do not match expectations in some way that we cannot recover from, we fallback to deriving the closure signature solely from those expected types.
    - For example, if the expected type is `u32` but the user wrote `i32`.
    - Or, more subtle, if the user wrote e.g. `&'x u32` for some named lifetime `'x`, but the expected type includes a bound lifetime (`for<'a> (&'a u32)`). In that case, preferring the type that the user explicitly wrote would hide an appearance of a bound name from the expected type, and we try to never do that.

The detailed rules that I came up with are found in the code, but for ease of reading I've also [excerpted them into a gist](https://gist.github.com/nikomatsakis/e69252a2b57e6d97d044c2f254c177f1). I am not convinced they are correct and would welcome feedback for alternative approaches.

(As an aside, the way I think I would ultimately *prefer* to think about this is that the conversion from HIR types to internal types could be parameterized by an "expected type" that it uses to guide itself. However, since that would be a pain, I opted *in the code* to first instantiate the supplied types as `Ty<'tcx>` and then "merge" those types with the `Ty<'tcx>` from the expected signature.)

I think we should probably FCP this before landing.

cc @rust-lang/lang
r? @arielb1

add #![allow(unused)] to the playground link rustdoc tests

rustdoc: add #[allow(unused)] to every doctest

also modify the order crate attributes are applied, to have a better
order of how things can override lints, either per-crate or per-test

Auto merge of #45759 - alexcrichton:update-openssl, r=sfackler

rustbuild: Update the OpenSSL version to link

This updates the OpenSSL tarball download to reflect OpenSSL's newest release.

Fix MIR inlining panic in generic function

Auto merge of #44042 - LukasKalbertodt:ascii-methods-on-instrinsics, r=alexcrichton

Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later

**EDIT:** [this PR is ready now](https://github.com/rust-lang/rust/pull/44042#issuecomment-333883548). I edited this post to reflect the current status of discussion, which is (apart from code review) pretty much settled.

---

This is my current progress in order to prepare stabilization of #39658. As discussed there (and in #39659), the idea is to deprecated `AsciiExt` and copy all methods to the type directly. Apparently there isn't really a reason to have those methods in an extension trait¹.

~~This is **work in progress**: copy&pasting code while slightly modifying the documentation isn't the most exciting thing to do. Therefore I wanted to already open this WIP PR after doing basically 1/4 of the job (copying methods to `&[u8]`, `char` and `&str` is still missing) to get some feedback before I continue. Some questions possibly worth discussing:~~

1. ~~Does everyone agree that deprecating `AsciiExt` is a good idea? Does everyone agree with the goal of this PR?~~ => apparently yes
2. ~~Are my changes OK so far? Did I do something wrong?~~
3. ~~The issue of the unstable-attribute is currently set to 0. I would wait until you say "Ok" to the whole thing, then create a tracking issue and then insert the correct issue id. Is that ok?~~
4. ~~I tweaked `eq_ignore_ascii_case()`: it now takes the argument `other: u8` instead of `other: &u8`. The latter was enforced by the trait. Since we're not bound to a trait anymore, we can drop the reference, ok?~~ => I reverted this, because the interface has to match the `AsciiExt` interface exactly.

¹ ~~Could it be that we can't write `impl [u8] {}`? This might be the reason for `AsciiExt`. If that is the case: is there a good reason we can't write such an impl block? What can we do instead?~~ => we couldn't at the time this PR was opened, but Simon made it possible.

/cc @SimonSapin @zackw

Relax #[deny(warnings)] in some crate for cargotest

Otherwise changes to the compiler are unable to introduce new
warnings: some crates tested by cargotest deny all warnings and
thus, the CI build fails.

Thanks SimonSapin for the patch!

Auto merge of #45754 - scottmcm:checked-npot, r=dtolnay

Fix #18604: next_power_of_two should panic on overflow

Fixes https://github.com/rust-lang/rust/issues/18604

Is it possible to write a test for this?  My experiments showed `x.py test` running in release mode, so my attempt at a `#[should_panic]` didn't work.

Auto merge of #45748 - petrochenkov:short, r=alexcrichton

Shorten paths to auxiliary files created by tests

I'm hitting issues with long file paths to object files created by the test suite, similar to https://github.com/rust-lang/rust/issues/45103#issuecomment-335622075.

If we look at the object file path in https://github.com/rust-lang/rust/issues/45103 we can see that the patch contains of few components:
```
specialization-cross-crate-defaults.stage2-x86_64-pc-windows-gnu.run-pass.libaux\specialization_cross_crate_defaults.specialization_cross_crate_defaults0.rust-cgu.o
```
=>

1. specialization-cross-crate-defaults // test name, required
2. stage2 // stage disambiguator, required
3. x86_64-pc-windows-gnu // target disambiguator, required
4. run-pass // mode disambiguator, rarely required
5. libaux // suffix, can be shortened
6. specialization_cross_crate_defaults // required, there may be several libraries in the directory
7. specialization_cross_crate_defaults0 // codegen unit name, can be shortened?
8. rust-cgu // suffix, can be shortened?
9. o // object file extension

This patch addresses items `4`, `5` and `8`.
`libaux` is shortened to `aux`, `rust-cgu` is shortened to `rcgu`, mode disambiguator is omitted unless it's necessary (for pretty-printing and debuginfo tests, see https://github.com/rust-lang/rust/pull/24537/commits/38d26d811a44ba93637c84ce77a58af88c47f0ac)

I haven't touched names of codegen units though (`specialization_cross_crate_defaults0`).
Is it useful for them to have descriptive names including the crate name, as opposed to just `0` or `cgu0` or something?

Auto merge of #45710 - alexcrichton:std-symbols, r=michaelwoerister

rustc: Handle some libstd symbole exports better

Right now symbol exports, particularly in a cdylib, are handled by
assuming that `pub extern` combined with `#[no_mangle]` means "export
this". This isn't actually what we want for some symbols that the
standard library uses to implement itself, for example symbols related
to allocation. Additionally other special symbols like
`rust_eh_personallity` have no need to be exported from cdylib crate
types (only needed in dylib crate types).

This commit updates how rustc handles these special symbols by adding to
the hardcoded logic of symbols like `rust_eh_personallity` but also
adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the
export level to be considered the same as all other Rust functions
instead of looking like a C function.

The eventual goal here is to prevent functions like `__rdl_alloc` from
showing up as part of a Rust cdylib as it's just an internal
implementation detail. This then further allows such symbols to get gc'd
by the linker when creating a cdylib.

Update reference link in doc's 404

It's currently linking to a page that says it's on the page I'm changing the link too.

rustc: Handle some libstd symbole exports better

Right now symbol exports, particularly in a cdylib, are handled by
assuming that `pub extern` combined with `#[no_mangle]` means "export
this". This isn't actually what we want for some symbols that the
standard library uses to implement itself, for example symbols related
to allocation. Additionally other special symbols like
`rust_eh_personallity` have no need to be exported from cdylib crate
types (only needed in dylib crate types).

This commit updates how rustc handles these special symbols by adding to
the hardcoded logic of symbols like `rust_eh_personallity` but also
adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the
export level to be considered the same as all other Rust functions
instead of looking like a C function.

The eventual goal here is to prevent functions like `__rdl_alloc` from
showing up as part of a Rust cdylib as it's just an internal
implementation detail. This then further allows such symbols to get gc'd
by the linker when creating a cdylib.

Use Add::add for overflow checks instead of [rustc_inherit_overflow_checks]

Fix comment formatting

Auto merge of #45711 - tirr-c:unicode-span, r=estebank

Display spans correctly when there are zero-width or wide characters

Hopefully...
* fixes #45211
* fixes #8706

---

Before:
```
error: invalid width `7` for integer literal
  --> unicode_2.rs:12:25
   |
12 |     let _ = ("a̐éö̲", 0u7);
   |                         ^^^
   |
   = help: valid widths are 8, 16, 32, 64 and 128

error: invalid width `42` for integer literal
  --> unicode_2.rs:13:20
   |
13 |     let _ = ("아あ", 1i42);
   |                    ^^^^
   |
   = help: valid widths are 8, 16, 32, 64 and 128

error: aborting due to 2 previous errors
```

After:
```
error: invalid width `7` for integer literal
  --> unicode_2.rs:12:25
   |
12 |     let _ = ("a̐éö̲", 0u7);
   |                     ^^^
   |
   = help: valid widths are 8, 16, 32, 64 and 128

error: invalid width `42` for integer literal
  --> unicode_2.rs:13:20
   |
13 |     let _ = ("아あ", 1i42);
   |                      ^^^^
   |
   = help: valid widths are 8, 16, 32, 64 and 128

error: aborting due to 2 previous errors
```

Spans might display incorrectly on the browser.

r? @estebank

Make DefIndex use newtype_index macro

Make DEBUG_FORMAT = custom work

Fixes #45763, ht by @durka

Remove import of now unused AsciiExt

I also replaced a wildcard import with a specific one, while I was
at it.

Auto merge of #45394 - davidtwco:rfc-2008, r=petrochenkov

RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute

This work-in-progress pull request contains my changes to implement [RFC 2008](https://github.com/rust-lang/rfcs/pull/2008). The related tracking issue is #44109.

As of writing, enum-related functionality is not included and there are some issues related to tuple/unit structs. Enum related tests are currently ignored.

WIP PR requested by @nikomatsakis [in Gitter](https://gitter.im/rust-impl-period/WG-compiler-middle?at=59e90e6297cedeb0482ade3e).

Ignoring pretty print for test due to #37199

Make DepNodeIndex use newtype_index macro

Auto merge of #45709 - nrc:rls-bugs-2, r=eddyb

Fix a bunch of minor save-analysis bugs

r? @eddyb

rustbuild: Update the OpenSSL version to link

This updates the OpenSSL tarball download to reflect OpenSSL's newest release.

rustbuild: don't try to install rls if ToolState is not Testing

The Dist Step is not ran in that case so we would end up trying to
install something that we didn't dist.

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

Add comment explaining the ctxt field in Span

Auto merge of #45617 - GuillaumeGomez:search-fixes, r=QuietMisdreavus

Search fixes

Fixes #45608.

r? @QuietMisdreavus

Auto merge of #45605 - Nashenas88:derive-newtype, r=nikomatsakis

Add derive and doc comment capabilities to newtype_index macro

This moves `RustcDecodable` and `RustcEncodable` out of the macro definition and into the macro uses. They were conflicting with `CrateNum`'s impls of `serialize::UseSpecializedEncodable` and `serialize::UseSpecializedDecodable`, and now it's not :). `CrateNum` is now defined with the `newtype_index` macro. I also added support for doc comments on constant definitions and allowed a type to remove the pub specification on the tuple param (otherwise a LOT of code would refuse to compile for `CrateNum`). I was getting dozens of errors like this if `CrateNum` was defined as `pub struct CrateNum(pub u32)`:
```
error[E0530]: match bindings cannot shadow tuple structs
   --> src/librustc/dep_graph/dep_node.rs:624:25
    |
63  | use hir::def_id::{CrateNum, DefId, DefIndex, CRATE_DEF_INDEX};
    |                   -------- a tuple struct `CrateNum` is imported here
...
624 |     [] MissingLangItems(CrateNum),
    |                         ^^^^^^^^ cannot be named the same as a tuple struct
```

I also cleaned up the formatting of the macro bodies as they were getting impossibly long. Should I go back and fix the matching rules to this style too?

I also want to see what the test results look like because `CrateNum` used to just derive `Debug`, but the `newtype_index` macro has a custom implementation. This might require further pushes.

Feel free to bikeshed on the macro language, I have no preference here.

Fix typos

Auto merge of #45755 - kennytm:rollup, r=kennytm

Rollup of 9 pull requests

- Successful merges: #45548, #45610, #45639, #45669, #45681, #45718, #45722, #45739, #45746
- Failed merges:

Rollup merge of #45746 - GuillaumeGomez:methods-doc-test, r=steveklabnik

Add tests for methods listing in rust docs

r? @rust-lang/docs

Rollup merge of #45739 - rkarp:master, r=petrochenkov

Fix libstd compile error for windows-gnu targets without `backtrace`

This is basically an addition to #44979. Compiling `libstd` still fails when targeting `windows-gnu` with `panic = "abort"` because the items in the `...c::gnu` module are not used. They are only referenced from `backtrace_gnu.rs`, which is indirectly feature gated behind `backtrace` [here](https://github.com/rust-lang/rust/blob/9f3b09116b742b2606dc5f36f9145e0c89e4010b/src/libstd/sys/windows/mod.rs#L23).

Rollup merge of #45722 - mikhail-m1:improve-mir-opt-error-output, r=alexcrichton

improve compiletest output for errors from mir-opt tests

improvement:
1. Report filename against general cannot open error
2. Report current MIR block

Rollup merge of #45718 - Ljzn:patch-2, r=BurntSushi

Fix typo

`accomodate` -> `accommodate`

Rollup merge of #45681 - Ljzn:patch-1, r=kennytm

Fix typo.

Rollup merge of #45669 - cardoe:metadata, r=kennytm

add Cargo metadata to libstd

Add license and repository metadata to libstd

Rollup merge of #45639 - LaurentMazare:master, r=petrochenkov

Add a nicer error message for missing  in for loop, fixes #40782.

As suggested by @estebank in issue #40782, this works in the same way as #42578: if the in keyword is missing, we continue parsing the expression and if this works correctly an adapted error message is produced. Otherwise we return the old error.

A specific test case has also been added.
This is my first PR on rust-lang/rust so any feedback is very welcome.

Rollup merge of #45610 - strake:atomic_from, r=nagisa

impl From<T> for AtomicT

Rollup merge of #45548 - ratmice:master, r=oli-obk

issue #45357 don't build clippy stage 1

#45357
Wasn't sure top_stage was the right thing, but seemed to go ahead building clippy stage 2.

Add overflow tests for next_power_of_two

Fix #18604: next_power_of_two should panic on overflow

Auto merge of #45514 - gnzlbg:jemalloc_realloc2, r=sfackler

[jemalloc] set correct excess in realloc_excess

Auto merge of #45384 - mikhail-m1:mir_add_false_edges_terminator_kind, r=arielb1

add TerminatorKind::FalseEdges and use it in matches

impl #45184 and fixes #45043 right way.

False edges unexpectedly affects uninitialized variables analysis in MIR borrowck.

Mark several ascii methods as unstable again

We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.

Remove unused AsciiExt imports and fix tests related to ascii methods

Many AsciiExt imports have become useless thanks to the inherent ascii
methods added in the last commits. These were removed. In some places, I
fully specified the ascii method being called to enforce usage of the
AsciiExt trait. Note that some imports are not removed but tagged with
a `#[cfg(stage0)]` attribute. This is necessary, because certain ascii
methods are not yet available in stage0. All those imports will be
removed later.

Additionally, failing tests were fixed. The test suite should exit
successfully now.

Copy `AsciiExt` methods to `str` directly

This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature this commit depends on: the
`slice_u8` lang item. Once this lang item is available in the
stage0 compiler, all those cfg flags (and more) can be removed.

Copy `AsciiExt` methods to `[u8]` directly

This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature I am using: the `slice_u8` lang item.
Once this lang item is available in the stage0 compiler, all those
cfg flags (and more) can be removed.

Add a lang item to allow `impl [u8] {…}` in the standard library

Fix lists in doc comments for ascii methods of u8 and char

Add missing space in match arm

Tweak documentation for `u8::eq_ignore_ascii_case()`

Remove examples in doc-comments of `AsciiExt` methods

The doc comments were incorrect before: since the inherent ascii methods
shadow the `AsciiExt` methods, the examples didn't use the `AsciiExt` at
all. Since the trait will be deprecated soon anyway, the easiest solution
was to remove the examples and already mention that the methods will be
deprecated in the near future.

Use direct implementation on u8/char to implement AsciiExt

The methods were copied to u8/char, so we can just use it in
AsciiExt impls to avoid duplicate code.

Copy `AsciiExt` methods to `char` directly

This is done in order to deprecate AsciiExt eventually.

Revert signature of eq_ignore_ascii_case() to original

Since the methods on u8 directly will shadow the AsciiExt methods,
we cannot change the signature without breaking everything. It
would have been nice to take `u8` as argument instead of `&u8`, but
we cannot break stuff! So this commit reverts it to the original
`&u8` version.

Make ascii methods on u8 insta-stable

Those methods will shadow the methods of `AsciiExt`, so if we don't
make them insta-stable, everyone will hitting stability errors. It
is fine adding those as stable, because they are just being moved
around [according to sfackler][1].

OPEN QUESTION: this commit also stabilizes the `AsciiExt` methods
that were previously feature gated by the `ascii_ctype` feature.
Maybe we don't want to stablilize those yet.

[1]: https://github.com/rust-lang/rust/pull/44042#issuecomment-329939279

Add all methods of AsciiExt to u8 directly

This is the first step in order to deprecate AsciiExt. Since
this is a WIP commit, there is still some code duplication (notably
the static arrays) that will be removed later.

Shorten paths to auxiliary files created by tests

Added page to unstable book.

Implemented RFC 2008 for enums (not including variants) and structs.

Added tests for RFC 2008.

Added feature gate for RFC 2008.

Auto merge of #45247 - leodasvacas:implement-auto-trait-syntax, r=nikomatsakis

[Syntax] Implement auto trait syntax

Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`.

See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231.

The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate.

When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet).

Observations:
- If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant.
- The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser.
- Rustfmt and clippy are broken, need to fix those.
- Rustdoc just ignores it for now.

ping @petrochenkov @nikomatsakis

Fix unsafe auto trait pretty print.

It was being printed wrong as auto unsafe trait