Don't run const propagation on items with inconsistent bounds
Fixes#67696
Using `#![feature(trivial_bounds)]`, it's possible to write functions
with unsatisfiable 'where' clauses, making them uncallable. However, the
user can act as if these 'where' clauses are true inside the body of the
function, leading to code that would normally be impossible to write.
Since const propgation can run even without any user-written calls to a
function, we need to explcitly check for these uncallable functions.
Reset Formatter flags on exit from pad_integral
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
A manual check leads me to believe this is the only case where we failed to reset the flags appropriately, but I could have missed something.
Add unreachable propagation mir optimization pass
@oli-obk suggested we create a MIR pass that optimizes away basic blocks that lead only to basic blocks with terminator kind **unreachable**. This is a first take on this, which we started with @gilescope at RustFest Impl Days.
The test currently fails when the compiled program runs (undefined behaviour). Is there a way to avoid running the compiled program?
perf: Eagerly convert literals to consts
Previousely even literal constants were being converted to an `Unevaluted` constant for evaluation later. This seems unecessary as no more information is needed to be able to convert the literal to a mir constant.
Hopefully this will also minimise the performance impact of #67717, as far less constant evaluations are needed.
Fix memory leak if C++ catches a Rust panic and discards it
If C++ catches a Rust panic using `catch (...)` and then chooses not to rethrow it, the `Box<dyn Any>` in the exception may be leaked. This PR fixes this by adding the necessary destructors to the exception object.
r? @Mark-Simulacrum
