It's a false dependency. The result isn't used and there are no
relevant side-effects.

`Compiler::register_plugins()` calls `passes::register_plugins()`, which
calls `Compiler::dep_graph_future()`. This is the only way in which a
`passes` function calls a `Compiler` function.

This commit moves the `dep_graph_future()` call out of
`passes::register_plugins()` and into `Compiler::register_plugins()`,
which is a more sensible spot for it. This will delay the loading of the
dep graph slightly -- from the middle of plugin registration to the end
of plugin registration -- but plugin registration is fast enough
(especially compared to expansion) that the impact should be neglible.

This will eventually allow us to easily pass in more parameters to the
functions without TLS or other such hacks

There's not really any reason to not have the visibility default to
inherited, and this saves us the trouble of checking everywhere for
whether we have a visibility or not.

This doesn't move everything over as cache() is pretty annoying to
remove fully, but it gets the ball rolling.

`Compiler::compile()` is different to all the other `Compiler` methods
because it lacks a `Queries` entry. It only has one call site, which is
in a test that doesn't need its specific characteristics.

This patch replaces that call with a call to `Compile::link()`, which is
similar enough for the test's purposes. It also notes that the method is
an illustrative example of how `Compiler` can be used.

mbe stands for macro-by-example

Then use the diagnostics-stealing API to stash parser
errors and enrich them with type information in typeck.

Use assert_eq and assert_ne over comparison operators.

Sync to rust-lang/rust master

Sync to rust-lang/rust master

remove rtp.rs and move rtpSpawn, RTP_ID_ERROR to libc

- In some places &str was shown instead of String.
- into_bytes is the reverse of from_utf8

Fixes rust-lang#63797

Fixes rust-lang#63677

RFC rust-lang#2071 (impl-trait-existential-types) does not explicitly state how
impl trait type alises should interact with coherence. However, there's
only one choice which makes sense - coherence should look at the
underlying type (i.e. the 'defining' type of the impl trait) of the type
alias, just like we do for non-impl-trait type aliases.

Specifically, impl trait type alises which resolve to a local type
should be treated like a local type with respect to coherence (e.g.
impl trait type aliases which resolve to a forieign type should be
treated as a foreign type, and those that resolve to a local type should
be treated as a local type).

Since neither inherent impls nor direct trait impl (i.e. `impl MyType`
or `impl MyTrait for MyType`) are allowd for type aliases, this
usually does not come up. Before we ever attempt to do coherence
checking, we will have errored out if an impl trait type alias was used
directly in an 'impl' clause.

However, during trait selection, we sometimes need to prove bounds like
'T: Sized' for some type 'T'. If 'T' is an impl trait type alias, this
requires to know the coherence behavior for impl trait type aliases when
we perform coherence checking.

Note: Since determining the underlying type of an impl trait type alias
requires us to perform body type checking, this commit causes us to type
check some bodies easlier than we otherwise would have. However, since
this is done through a query, this shouldn't cause any problems

For completeness, I've added an additional test of the coherence-related
behavior of impl trait type aliases.

Issue#63183: Add fs::read_dir() and ReadDir warning about iterator order + example

As per rust-lang#63183

Add warning about iterator order to read_dir and ReadDir, add example of explicitly ordering direntrys.

… r=nikomatsakis

Fix coherence checking for impl trait in type aliases

**UPDATE**: This PR now treats all opaque types as remote. The original description appears below, but is no longer accurate.

Fixes rust-lang#63677

[RFC 2071](rust-lang/rfcs#2071) (impl-trait-existential-types) does not explicitly state how `type_alias_impl_trait` should interact with coherence. However, there's only one choice which makes sense - coherence should look at the underlying type (i.e. the *"defining"* type of the `impl Trait`) of the type alias, just like we do for non-`impl Trait` type aliases.

Specifically, `impl Trait` type aliases that resolve to a local type should be treated like a local type with respect to coherence (e.g. `impl Trait` type aliases which resolve to a foreign type should be treated as a foreign type, and those that resolve to a local type should be treated as a local type).

Since neither inherent impls nor direct trait impl (i.e. `impl MyType` or `impl MyTrait for MyType`) are allowed for type aliases, this usually does not come up. Before we ever attempt to do coherence checking, we will have errored out if an `impl Trait` type alias was used directly in an `impl` clause.

However, during trait selection, we sometimes need to prove bounds like `T: Sized` for some type `T`. If `T` is an impl trait type alias, this requires to know the coherence behavior for `impl Trait` type aliases when we perform coherence checking.

Note: Since determining the underlying type of an `impl Trait` type alias requires us to perform body type checking, this commit causes us to type check some bodies easier than we otherwise would have. However, since this is done through a query, this shouldn't cause any problems

For completeness, I've added an additional test of the coherence-related behavior of `impl Trait` type aliases.

cc rust-lang#63063

…i-obk

Streamline `Compiler`

A few commits to clean up `Compiler`.

r? @Zoxc

Document the unstable iter_order_by library feature

Tracking issue: rust-lang#64295

Follow-up for: rust-lang#62205

References the tracking issue and adds a page to the unstable book for the new unstable `iter_order_by` feature.

…GuillaumeGomez

rustdoc: general cleanup

Review should be conducted commit-by-commit.

There are some general cleanup commits in the end, which are somewhat related but can be easily split into another PR, so just let me know.

…i-obk

Add a cycle detector for generic `Graph`s and `mir::Body`s

Cycle detection is one way to differentiate the upcoming `const_loop` feature flag (rust-lang#52000) from the `const_if_match` one (rust-lang#49146). It would be possible to use the existing implementation of strongly-connected components for this but less efficient.

The ["tri-color" terminology](http://www.cs.cornell.edu/courses/cs2112/2012sp/lectures/lec24/lec24-12sp.html) is common in introductory data structures and algorithms courses: black nodes are settled, grey nodes are visited, and white nodes have no state. This particular implementation is iterative and uses a well-known technique where "node settled" events are kept on the stack alongside nodes to visit. When a settled event is popped, we know that all successors of that node have been visited and themselves settled. If we encounter a successor node that has been visited (is on the stack) but not yet settled, we have found a cycle.

r? @eddyb

Refactor macro by example

This doesn't do anything useful yet, and just moves code around and restricts visibility

…stebank

Recover on `const X = 42;` and infer type + Error Stash API

Here we:

1. Introduce a notion of the "error stash".

   This is a map in the `Handler` to which you can `err.stash(...)` away your diagnostics and then steal them in a later "phase" of the compiler (e.g. stash in parser, steal in typeck) to enrich them with more information that isn't available in the previous "phase".

    I believe I've covered all the bases to make sure these diagnostics are actually emitted eventually even under `#[cfg(FALSE)]` but please check my logic.

2. Recover when parsing `[const | static mut?] $ident = $expr;` which has a missing type.

    Use the "error stash" to stash away the error and later steal the error in typeck where we emit the error as `MachineApplicable` with the actual inferred type. This builds on rust-lang#62804.

cc rust-lang/rfcs#2545

r? @estebank

Remove unused dependencies

update mem::discriminant test to use assert_eq and assert_ne over comparison operators

Use assert_eq and assert_ne over comparison operators.

 remove rtp.rs, and move rtpSpawn and RTP_ID_ERROR to libc

r? @alexcrichton

Fixed issue from rust-lang#64447

Did two tiny fixes. One is a micro optimization since we know that max is going to be assigned a `usize`, we do not have to worry about a possible negative number.
The other issue that was fixed is that the max from the children isn't updated correctly. Now it will use `sub_result` instead of `primary` and will properly get the needed value.

fix one typo

fix several issues in String docs

- In some places &str was shown instead of String.
- into_bytes is the reverse of from_utf8

Fixes rust-lang#63797

I've retaken the work done in this PR: rust-lang#63865 which for some reason was closed.
and just done a minor change (I hope you don't mind @sam09 ).

…-Simulacrum

relnotes: make compatibility section more sterile and fix rustc version

r? @Mark-Simulacrum

Fix rust-lang#64744. Account for the Zero sub-pattern case.

Fixes rust-lang#64744.

r? @estebank