Do not ICE when failing to normalize in ConstProp.
There is no reason to delay a bug there, as we bubble up the failure as TooGeneric.
Fixes https://github.com/rust-lang/rust/issues/97728
Check for free regions in MIR validation
This turns https://github.com/rust-lang/rust/issues/108720 into a MIR validation failure that will reproduce without debug-assertions enabled.
```
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:296 ~ futures_util[3805]::future::future::remote_handle::{impl#3}::poll), const_param_did: None }) (after pass ScalarReplacementOfAggregates) at bb0[0]:
Free regions in optimized runtime-post-cleanup MIR
--> /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.26/src/future/future/remote_handle.rs:96:13
|
96 | let this = self.project();
| ^^^^
```
Add regression tests for issue 70919
Desugaring DropAndReplace at MIR build (#107844) fixed#70919.
Add regressions tests, borrowed from #102078, to ensure we check for this in the future.
cc ``@Aaron1011``
const_eval: `implies_by` in `rustc_const_unstable`
Fixes#107605.
Extend support for `implies_by` (from `#[stable]` and `#[unstable]`) to `#[rustc_const_stable]` and `#[rustc_const_unstable]`.
cc ``@steffahn``
Allow using `bool` instead of `Option<()>` in diagnostics
~~Disallow the unit type for `#[help]`, `#[note]` etc, instead using `bool` to express optional annotations without a span which I believe is more intuitive.~~
~~Test output ordering has changed in a few places, where a field was of type `()` and the annotation has been moved to the struct itself. If any of these changes are an issue, this can be restricted to allowing specifically `()`, and not `Option<()>`~~
~~Actual changes here: https://github.com/rust-lang/rust/pull/108402/files#diff-815b1d8debfc564112bd51093791d7c3f2ee288a37a8f5c0e89c11d1f609b4c0~~
Allows using `bool` in derive diagnostics to indicate an optional subdiagnostic without a span, where previously `Option<()>` had to be used
`@rustbot` label +A-diagnostics
internal: Re-use the resolver in `InferenceContext` instead of rebuilding it whenever needed
This reduced inference time on my local build by roughly ~1 sec (out of like 60)
