To check if a method's receiver type is object safe, we create a new receiver type by substituting in a bogus type parameter (let's call it `U`) for `Self`, and checking that the unmodified receiver type implements `DispatchFromDyn<receiver type with Self = U>`. It would be better to use `dyn Trait` directly, and the only reason we don't is because it triggers another check that `Trait` is object safe, resulting in a query cycle. Once the feature `object_safe_for_dispatch` (tracking issue rust-lang#43561) is stabilized, this will no longer be the case, and we'll be able to use `dyn Trait` as the unsized `Self` type. I've updated the comments in object_safety.rs accordingly.

Uploading the toolstate data for each commit will help our release
tooling understand which components are failing, to possibly skip
shipping broken tools to users.

Co-Authored-By: lzutao <taolzu@gmail.com>

Replace O(n^3) text matching with inexpensive hash set lookups.

On my machine this reduces the total runtime of complete
run-make-fulldeps suite from roughly 75 seconds to 45 seconds.

This causes issues in at least `dist-i586-gnu-i586-i686-musl`,
possibly others.

…nikomatsakis

Custom lifetime error for `impl` item doesn't conform to `trait`

Partly addresses rust-lang#42706, rust-lang#41343, fix rust-lang#40900.

Add lint and tests for unnecessary parens around types

This is my first contribution to the Rust project, so I apologize if I'm not doing things the right way.

The PR fixes rust-lang#64169. It adds a lint and tests for unnecessary parentheses around types. I've run `tidy` and `rustfmt` — I'm not totally sure it worked right, though — and I've tried to follow the instructions linked in the readme.

I tried to think through all the variants of `ast::TyKind` to find exceptions to this lint, and I could only find the one mentioned in the original issue, which concerns types with `dyn`. I'm not a Rust expert, thought, so I may well be missing something.

There's also a problem with getting this to build. The new lint catches several things in the, e.g., `core`. Because `x.py` seems to build with an equivalent of `-Werror`, what would have been warnings cause the build to break. I got it to build and the tests to pass with `--warnings warn` on my `x.py build` and `x.py test` commands.

build-std compatible sanitizer support

### Motivation

When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.

The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.

The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:

```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```

### Implementation

* Sanitizer runtimes are no long packed into crates. Instead, libraries build
  from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
  they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue rust-lang#64629.
  (in previous design it was hard to avoid linking runtimes into static
  libraries produced by rustc as demonstrated by sanitizer-staticlib-link
  test, which still passes despite changes made in rust-lang#64780).
* When custom llvm-config is specified during build process, the sanitizer
  runtimes will be obtained from there instead of begin rebuilding from sources
  in src/llvm-project/compiler-rt. This should be preferable since runtimes
  used should match instrumentation passes. For example there have been nine
  version of address sanitizer ABI.

Note this marked as a draft PR, because it is currently untested on OS X (I
would appreciate any help there).

cc @kennytm, @japaric, @Firstyear, @choller

…=alexcrichton

Upload toolstates.json to rust-lang-ci2

This PR does two things:

* Following up with rust-lang#65202, it migrates deploying artifacts to CI in a script. Both uploading release artifacts and CPU stats were merged into the same script, designing it to be easily extended.
* Uploads the toolstate JSON to `rust-lang-ci2` along with the release artifacts, both for Linux and Windows. This is needed because @RalfJung wants to stop shipping MIRI when its tests are failing, and the toolstate repo doesn't have entries for each commit. Having the toolstate data (just for that specific commit) on `rust-lang-ci2` will simplify the code a lot.

r? @alexcrichton
cc @RalfJung

Update comments re type parameter hack in object safety

To check if a method's receiver type is object safe, we create a new receiver type by substituting in a bogus type parameter (let's call it `U`) for `Self`, and checking that the unmodified receiver type implements `DispatchFromDyn<receiver type with Self = U>`. It would be better to use `dyn Trait` directly, and the only reason we don't is because it triggers another check that `Trait` is object safe, resulting in a query cycle. Once the feature `object_safe_for_dispatch` (tracking issue rust-lang#43561) is stabilized, this will no longer be the case, and we'll be able to use `dyn Trait` as the unsized `Self` type. I've updated the comments in object_safety.rs accordingly.

cc @Centril @nikomatsakis @bovinebuddha

…davidtwco

Use structured suggestion for unnecessary bounds in type aliases

…=alexcrichton

Optimize long-linker-command-line test

Replace O(n^3) text matching with inexpensive hash set lookups.

On my machine this reduces the total runtime of complete
run-make-fulldeps suite from roughly 75 seconds to 45 seconds.