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 https://github.com/rust-lang/rust/pull/62804.
cc https://github.com/rust-lang/rfcs/pull/2545
r? @estebank
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 (#52000) from the `const_if_match` one (#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
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.
Document the unstable iter_order_by library feature
Tracking issue: #64295
Follow-up for: #62205
References the tracking issue and adds a page to the unstable book for the new unstable `iter_order_by` feature.
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#63677
[RFC 2071](https://github.com/rust-lang/rfcs/pull/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 https://github.com/rust-lang/rust/issues/63063
Issue#63183: Add fs::read_dir() and ReadDir warning about iterator order + example
As per https://github.com/rust-lang/rust/issues/63183
Add warning about iterator order to read_dir and ReadDir, add example of explicitly ordering direntrys.
Remove blanket check for existence of other errors before emitting
"type annotation needed" errors, and add some eager checks to avoid
adding obligations when they refer to types that reference
`[type error]` in order to reduce unneded errors.
Fixes#63677
RFC #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.
Stabilize `str::len`, `[T]::len` and `str::as_bytes` as const fn
r? @Centril
cc @RalfJung
This also introduces a scheme for making certain feature gates legal in stabilized const fns
Delete most of `src/bootstrap/bin/rustc.rs`
This commit is an attempt at deleting as much of the `rustc.rs` shim that we have in rustbuild as possible. This shim predates `RUSTFLAGS` and is as old as rustbuild itself. While useful for quick hacks, it subverts Cargo's knowledge of `rustc`, makes it more difficult to build crates out of rustbuild, and is generally a hazard/code smell due to its architecture.
Additionally since the inception of this script we've added a number of features to Cargo such as profile overrides and `RUSTFLAGS`. This commit attempts to use these features of Cargo as much as possible to delete almost all of `src/bootstrap/bin/rustc.rs`. It's hoped that all new configuration for the Rust compiler can be codified in rustbuild rather than in this shim, allowing Cargo to have more knowledge about what's going on and making it a bit easier to reproduce builds outside of Cargo itself.
This was primarily motivated by some recent work on std-aware Cargo, and is also generally a cleanup of the script itself. This internally resulted in a number of refactorings of rustbuild itself, and the commits should be readable one-at-a-time instead of having to digest them all at once.
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Closes#64319
This commit converts a field of `Session`, `dependency_formats`, into a
query of `TyCtxt`. This information then also needed to be threaded
through to other remaining portions of the linker, but it's relatively
straightforward. The only change here is that instead of
`HashMap<CrateType, T>` the data structure changed to `Vec<(CrateType,
T)>` to make it easier to deal with in queries.
This is needed to ensure that the crates during a normal build are
shared with the crates during testing, otherwise they'll end up hasing
differently and we'll recompile crates like `core` during tests.
