Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Fix#56368.
Make dataflow-based const qualification the canonical one
For over a month, dataflow-based const qualification has been running in parallel with `qualify_consts` to check the bodies of `const` and `static`s. This PR removes the old qualification pass completely in favor of the dataflow-based one.
**edit:**
This PR also stops checking `QUALIF_ERROR_BIT` during promotion. This check appears to no longer serve a purpose now that the CTFE engine is more robust.
As a side-effect, this resolves#66167.
r? @eddyb
Use "field is never read" instead of "field is never used"
this is my first PR here so please let me know if i am doing it wrong
closes#64465
i will be referencing this with a book PR that updates the same language
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Rollup of 5 pull requests
Successful merges:
- #66350 (protect creation of destructors by a mutex)
- #66407 (Add more tests for fixed ICEs)
- #66415 (Add --force-run-in-process unstable option to libtest)
- #66427 (Move the JSON error emitter to librustc_errors)
- #66441 (libpanic_unwind for Miri: make sure we have the SEH lang items when needed)
Failed merges:
r? @ghost
Refactor integer range handling in the usefulness algorithm
Integer range handling had accumulated a lot of debt. This cleans up a lot of it.
In particular this:
- removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange`
- clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans
- cleans up some overly complicated code paths
- generally tries to be more idiomatic.
As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`.
There's one thing that I feel remains to clean up: the [overlapping range check](https://github.com/rust-lang/rust/pull/64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR.
There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Add --force-run-in-process unstable option to libtest
When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process.
For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :).
r? @alexcrichton
cc @cramertj,@petrhosek
Add more tests for fixed ICEs
Closes#36122 (fixed in 1.20.0)
Closes#58094 (fixed in #66054)
Also, fix mistaken test case, from #30904 to #30906 (cc @eddyb)
r? @Centril
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering
We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.
r? @varkor
Remove cannot mutate statics in initializer of another static error
r? @oli-obk
This is just a refactoring. As the removed code itself said, it only a heuristic catching a few cases early instead of leaving it all to const eval. It's easy to work around the static check and then run into the miri-engine check.
