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.
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
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`.
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`.
Tweak output for invalid negative impl errors
Follow up to #69722. Tweak negative impl errors emitted in the HIR:
```
error[E0192]: invalid negative impl
--> $DIR/E0192.rs:9:6
|
LL | impl !Trait for Foo { }
| ^^^^^^
|
= note: negative impls are only allowed for auto traits, like `Send` and `Sync`
```
Rollup of 8 pull requests
Successful merges:
- #69080 (rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.)
- #69940 (librustc_codegen_llvm: Replace deprecated API usage)
- #69942 (Increase verbosity when suggesting subtle code changes)
- #69968 (rustc: keep upvars tupled in {Closure,Generator}Substs.)
- #70123 (Ensure LLVM is in the link path for rustc tools)
- #70159 (Update the bundled wasi-libc with libstd)
- #70233 (resolve: Do not resolve visibilities on proc macro definitions twice)
- #70286 (Miri error type: remove UbExperimental variant)
Failed merges:
r? @ghost
Miri error type: remove UbExperimental variant
In https://github.com/rust-lang/miri/pull/1250, I will move Miri away from that variant, and use a custom `MachineStop` exception instead.
