Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
Rollup of 6 pull requests
Successful merges:
- #65566 (Use heuristics to suggest assignment)
- #65738 (Coherence should allow fundamental types to impl traits when they are local)
- #65777 (Don't ICE for completely unexpandable `impl Trait` types)
- #65834 (Remove lint callback from driver)
- #65839 (Clean up `check_consts` now that new promotion pass is implemented)
- #65855 (Add long error explaination for E0666)
Failed merges:
r? @ghost
Clean up `check_consts` now that new promotion pass is implemented
`check_consts::resolver` contained a layer of abstraction (`QualifResolver`) to allow the existing, eager style of qualif propagation to work with either a dataflow results cursor or by applying the transfer function directly (if dataflow was not needed e.g. for promotion). However, #63812 uses a different, lazy paradigm for checking promotability, which makes this unnecessary. This PR cleans up `check_consts::validation` to use `FlowSensitiveResolver` directly, instead of through the now obselete `QualifResolver` API.
Also, this contains a few commits (the first four) that address some FIXMEs in #63812 regarding code duplication. They could be split out, but I think they will be relatively noncontroversial? Notably, `validation::Mode` is renamed to `ConstKind` and used in `promote_consts` to denote what kind of item we are in.
This is best reviewed commit-by-commit and is low priority.
r? @eddyb
Remove lint callback from driver
This is leftover from a restructuring of lint registration for drivers; it should now happen via the register_lints field on Config rather than this function.
This is not used by anyone to my knowledge (including the compiler itself); it was introduced in an abandoned refactor in #65193.
Don't ICE for completely unexpandable `impl Trait` types
Save the resolution of these types (to themselves) to the typeck tables so that they will eventually reach E0720.
closes#65561
Coherence should allow fundamental types to impl traits when they are local
After #64414, `impl<T> Remote for Box<T> { }` is disallowed, but it is also disallowed in liballoc, where `Box` is a local type!
Enabling `#![feature(re_rebalance_coherence)]` in `liballoc` results in:
```
error[E0210]: type parameter `F` must be used as the type parameter for some local type (e.g., `MyStruct<F>`)
--> src\liballoc\boxed.rs:1098:1
|
1098 | impl<F: ?Sized + Future + Unpin> Future for Box<F> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type parameter `F` must be used as the type parameter for some local type
```
This PR relaxes `uncover_fundamental_ty` to skip local fundamental types.
I didn't add a test since `liballoc` already fails to compile, but I can add one if needed.
r? @nikomatsakis
cc #63599
Use heuristics to suggest assignment
When detecting a possible `=` -> `:` typo in a `let` binding, suggest
assigning instead of setting the type.
Partially address #57828.
rustc: add `Span`s to `inferred_outlives_of` predicates.
This would simplify #59789, and I suspect it has some potential in diagnostics (although we don't seem to use the predicate `Span`s much atm).
trait-based structural match implementation
Moves from using a `#[structural_match]` attribute to using a marker trait (or pair of such traits, really) instead.
Fix#63438.
(This however does not remove the hacks that I believe were put into place to support the previous approach of injecting the attribute based on the presence of both derives... I have left that for follow-on work.)
Redesign the interface to the unikernel HermitCore
We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs.
We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
Rollup of 8 pull requests
Successful merges:
- #65743 (rustc_typeck: don't record direct callees in generator_interior.)
- #65761 (libsyntax: Enhance documentation of the AST module)
- #65772 (Remove the last remaining READMEs)
- #65773 (Increase spacing for suggestions in diagnostics)
- #65791 (Adding doc on keyword continue)
- #65824 (rustc: make DefPathData (and friends) Copy (now that it uses Symbol).)
- #65828 (Derive Eq and Hash for SourceInfo again)
- #65842 (Add more information on rustdoc search)
Failed merges:
- #65825 (rustc: use IndexVec<DefIndex, T> instead of Vec<T>.)
r? @ghost
Increase spacing for suggestions in diagnostics
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
r? @Centril
libsyntax: Enhance documentation of the AST module
This PR enhances documentation state to the `libsyntax/ast.rs` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
- Minor style fixes to improve module readability.
rustc_typeck: don't record direct callees in generator_interior.
For expressions like `f(g().await)` we were recording `f` as needing to be kept in a temporary (and therefore be tracked by the generator type) across the suspend, even if a function/method path.
However, this is never needed, and can cause issues with complex function types (see #65244).
cc @Zoxc @nikomatsakis
This is a relic from earlier attempts at dataflow-based const validation
that attempted to do promotion at the same time. #63812 takes a
different approach: `IsNotPromotable` is no longer a `Qualif` and is
computed lazily instead of eagerly. As a result, there's no need for an
eager `TempPromotionResolver`, and we can use the only implementer of
`QualifResolver` directly instead of through a trait.
rustc_mir: double-check const-promotion candidates for sanity.
Previously, const promotion involved tracking information about the value in a MIR local (or any part of the computation leading up to that value), aka "qualifs", in a quite stateful manner, which is hard to extend to arbitrary CFGs without a dataflow pass.
However, the nature of the promotion we do is that it's effectively an SSA-like "tree" (or DAG, really), of assigned-once locals - which is how we can take them from the original MIR in the first place.
This structure means that the subset of the MIR responsible for computing any given part of a const-promoted value is readily analyzable by walking that tree/DAG.
This PR implements such an analysis in `promote_consts`, reusing the `HasMutInterior` / `NeedsDrop` computation from `qualify_consts`, but reimplementing the equivalent of `IsNotPromotable` / `IsNotImplicitlyPromotable`.
Eventually we should be able to remove `IsNotPromotable` / `IsNotImplicitlyPromotable` from `qualify_consts`, which will simplify @ecstatic-morse's dataflow-based const-checking efforts.
But currently this is mainly for a crater check-only run - it will compare the results from the old promotion collection and the new promotion validation and ICE if they don't match.
r? @oli-obk
This is leftover from a restructuring of lint registration for drivers;
it should now happen via the register_lints field on Config rather than
this function.
