Rollup of 8 pull requests
Successful merges:
- #68884 (Make the `type_of` return a generic type for generators)
- #69788 (Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book)
- #70074 (Expand: nix all fatal errors)
- #70077 (Store idents for `DefPathData` into crate metadata)
- #70213 (traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).)
- #70259 (Use Reveal::All in MIR optimizations)
- #70284 (correctly handle const params in type_of)
- #70289 (Refactor `codegen`)
Failed merges:
r? @ghost
Refactor `codegen`
`codegen` in `src/librustc_codegen_llvm/back/write.rs` is long and has complex control flow. These commits refactor it and make it easier to understand.
traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).
This PR addresses the representation side of #70180, but only *actually collects* `ty::Infer`s via `Ty::walk` into `stalled_on` (collecting `ty::ConstKind::Infer`s requires #70164).
However, it should be enough to handle #70107's needs (WF obligations are stalled only on the outermost type/const being an inference variable, no `walk`-ing is involved).
This is my second attempt, see #70181 for the previous one, which unacceptably regressed perf.
r? @nikomatsakis cc @nnethercote
Store idents for `DefPathData` into crate metadata
Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.
We now store the identifier's `Span` in a side table, which gets encoded
into the crate metadata. When we decode items from the metadata, we
combine the name and span back into an `Ident`.
This improves the output of several tests, which previously had messages
suppressed due to dummy spans.
This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.
Expand: nix all fatal errors
Basically, we go after all `.span_fatal` / `FatalError.raise()` and similar things and remove them one by one until there are no fatal errors left.
r? @petrochenkov
Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book
A simple fix in docs - the sequence of words in basic example of negative trait implementation was reversed.
Rollup of 11 pull requests
Successful merges:
- #67761 (Move the dep_graph construction to a dedicated crate.)
- #69740 (Replace some desc logic in librustc_lint with article_and_desc)
- #69981 (Evaluate repeat expression lengths as late as possible)
- #70087 (Remove const eval loop detector)
- #70242 (Improve E0308 error message wording)
- #70264 (Fix invalid suggestion on `&mut` iterators yielding `&` references)
- #70267 (get rid of ConstPropUnsupported; use ZST marker structs instead)
- #70277 (Remove `ReClosureBound`)
- #70283 (Add regression test for #70155.)
- #70294 (Account for bad placeholder types in where clauses)
- #70309 (Clean up E0452 explanation)
Failed merges:
r? @ghost
Add regression test for #70155.
With #70166 merged, `RangeInclusive` now derives `PartialEq` and `Eq`, implementing structural equality and as a side effect the range is now usable with const generics, closing #70155.
As per [#70166 (comment)](https://github.com/rust-lang/rust/pull/70166#issuecomment-601872201) a test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting #70155.
Fix invalid suggestion on `&mut` iterators yielding `&` references
Fixes#69789.
rustc suggested an invalid code when `&` reference from `&mut` iterator is mutated. The compiler knew we're mutating a value behind `&` reference, but as the assignment RHS is from desugaring, it could only see the iterator expression from source and inserted `mut` there.
r? @estebank
Improve E0308 error message wording
Hi folks,
I made [a post on Reddit](https://old.reddit.com/r/rust/comments/fmi11x/consider_linting_rusts_documentationerror_text/) about how (IMO) the docs/error messages can be a bit intimidating, one thing led to another, and I was encouraged to submit a Pull Request if I felt I could re-phrase the error message that I used as an example.
So that's this Pull Request. Open to any feedback or style changes, and I understand this is subjective.
(On another note: I am happy to see [this message was recently improved](https://github.com/rust-lang/rust/pull/69139) in `master`, so it's already better than it is in stable Rust 1.42.0.)
Ideally the last sentence could be split into at least two: [sentence explaining the inferred type.] [Sentence explaining explicit type.] [Sentence that summarizes that "this is bad," and why.]
But I'm not sure how to do so; I'm wary of writing something that turns out to be technically incorrect.
Remove const eval loop detector
Now that there is a configurable instruction limit for CTFE (see #67260), we can replace the loop detector with something much simpler. See #66946 for more discussion about this. Although the instruction limit is nightly-only, the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable).
This will at the very least require a crater run, since it will result in an error wherever the "long running const eval" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this.
Resolves#54384 cc #49980
r? @oli-obk cc @RalfJung
Move the dep_graph construction to a dedicated crate.
The interface for librustc consists in two traits: `DepKind` and `DepContext`.
The `DepKind` is the main interface. It allows to probe properties of the dependency.
As before, `DepNode` is the pair of a `DepKind` object and a hash fingerprint.
The `DepContext` takes the place of the `TyCtxt`, and handles communication with the query engine.
The use of the `ImplicitCtxt` through `ty::tls` is done through the `DepKind` trait.
This may not be the best choice, but it seemed like the simplest.
XAMPPRocky
Erin Power
bors
Mazdak Farrokhzad
Oliver Scherer
Camille GILLOT