This is only to make the generated DOT more legible.

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.

…d by vxWorks

These are the repositories I've moved from rust-lang-nursery to
rust-lang, so we should update the submodules too.

It remains as a comment in `error_codes.rs` for consistency with
other unused errors.

If __LITTLE_ENDIAN__ is missing, libunwind assumes big endian
and reads unwinding instructions wrong on ARM EHABI.

Fix rust-lang#65765

Module level docs should resolve intra-doc links as locally as
possible.  As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.

Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>

…ed type

vxWorks: remove all code related to UNIX socket as it is not supporte…

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.

…=estebank

Fix `-Zunpretty=mir-cfg` to render multiple items

`-Zunpretty=mir-cfg` outputs DOT to stdout for all items being compiled. However, it puts all of these items in separate `digraph`s, which means the result of redirecting that output to a file is not valid. Most dot renderers (I have tried `dot` and `xdot`) cannot render the output.

This PR checks to see if `write_mir_graphviz` will  process multiple items, and writes them each as a `subgraph` in a single, top-level `digraph`. As a result, DOT can be viewed without manually editing the output file. The output is unchanged when printing a single item (e.g.`-Zunpretty=mir-cfg=item_name`).

Here's the output of `xdot` for a rust file containing three items:
![three-items](https://user-images.githubusercontent.com/29463364/66889712-4bf62200-ef98-11e9-83b5-60faa2a300dd.png)

The borders are a result of the nonstandard–but well-supported–[`cluster` prefix](https://graphviz.gitlab.io/_pages/doc/info/lang.html) (search for "Subgraphs and Clusters"). They will not appear if your renderer does not support this extension, but the graph will still render properly.

…-E0578, r=Dylan-DPC

Add long error explanation for E0578

Part of rust-lang#61137

r? @kinnison

…nisheart,GuillaumeGomez

rustdoc: Resolve module-level doc references more locally

Module level docs should resolve intra-doc links as locally as
possible.  As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.

I'm hoping that this fixes rust-lang#55364 though right now I'm not sure it's the right fix.

r? @GuillaumeGomez

…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.

… r=eddyb

Make `promote_consts` emit the errors when required promotion fails

A very minimal version of rust-lang#65942.

This will cause a generic "argument X is required to be a constant" message for `simd_shuffle` LLVM intrinsics instead of the [custom one](https://github.com/rust-lang/rust/blob/caa1f8d7b3b021c86a70ff62d23a07d97acff4c4/src/librustc_mir/transform/qualify_consts.rs#L1616). It may be possible to remove this special-casing altogether after rust-lang/stdarch#825.

r? @eddyb

doc: reword iter module example and mention other methods

…entril

update submodules to rust-lang

These are the repositories I've moved from rust-lang-nursery to
rust-lang, so we should update the submodules too.

I have not tested that this builds at all, so please make sure CI is green!

…ichton

Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets

If `__LITTLE_ENDIAN__` is missing, libunwind assumes big endian
and reads unwinding instructions wrong on ARM EHABI.

Fix rust-lang#65765

Technical background in referenced bug.

I didn't run any automated tests, just built a simple panicking program using the fixed toolchain and panicking started to work. Tried with `catch_unwind()` and that seems to work now too. libunwind's log seems ok now, I can paste it if needed.

…-with-an-associated-type, r=estebank

Fix incorrect diagnostics for expected type in E0271 with an associated type

With code like the following code:

```rust
#[derive(Debug)]
struct Data {}

fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
    for item in iterator {
        println!("{:?}", item)
    }
}

fn main() {
    let v = vec![Data {}];

    do_stuff(v.into_iter());
}
```

the diagnostic (in nightly & stable) wrongly complains about the expected type:

```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
  --> src/main.rs:15:5
   |
5  | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
   |    --------                             --------------- required by this bound in `do_stuff`
...
15 |     do_stuff(v.into_iter());
   |     ^^^^^^^^ expected struct `Data`, found &Data
   |
   = note: expected type `Data`
              found type `&Data`
```

This PR fixes this issue by flipping the expected/actual values where appropriate, so it looks like this:

```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
  --> main.rs:15:5
   |
5  | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
   |    --------                             --------------- required by this bound in `do_stuff`
...
15 |     do_stuff(v.into_iter());
   |     ^^^^^^^^ expected &Data, found struct `Data`
   |
   = note: expected type `&Data`
              found type `Data`
```

This improves the output of a lot of existing tests (check out `associated-types-binding-to-type-defined-in-supertrait`!).

The only change which I wasn't too sure about is in the test `associated-types-overridden-binding-2`, but I think it's an improvement and the underlying problem is with handling of `trait_alias`.

Fix rust-lang#57226, fix rust-lang#64760, fix rust-lang#58092.

…r=estebank

Add error code E0743 for "C-variadic has been used on a non-foreign function"

Fixes rust-lang#65967

…, r=Mark-Simulacrum

Fix outdated rustdoc of Once::init_locking function

r? @Mark-Simulacrum

related to rust-lang#65979

vxWorks: remove code related unix socket

r? @alexcrichton