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.
submodules: update clippy from d8e6e4cf to 1ff81c1b
Changes:
````
rustup https://github.com/rust-lang/rust/pull/69968/
Fix documentation generation for configurable lints
Fix single binding in closure
Improvement: Don't show function body in needless_lifetimes
````
Fixes#70310
r? @Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #68700 (Add Wake trait for safe construction of Wakers.)
- #69494 (Stabilize --crate-version option in rustdoc)
- #70080 (rustc_mir: remove extra space when pretty-printing MIR.)
- #70195 (Add test for issue #53275)
- #70199 (Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.)
- #70299 (add err_machine_stop macro)
- #70300 (Reword unused variable warning)
- #70315 (Rename remaining occurences of Void to Opaque.)
- #70318 (Split long derive lists into two derive attributes.)
Failed merges:
r? @ghost
In addition to the regression test of `RangeInclusive` for #70155, now all range types are checked for usability within const generics:
- `RangeFrom`
- `RangeFull`
- `RangeToInclusive`
- `RangeTo`
- `Range`
The test are moved from `test\ui\const-generics\issues\issue-70155` to `test\ui\const-generics\std\range` in anticipation of future similar tests for std types.
Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.
This required revising some of the client code to stop relying on the returned set of lines being non-empty.
Fix#68808
Add Wake trait for safe construction of Wakers.
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`.
Therefore, the Wake trait was left out of the initial version of the task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
