…Nilstrieb

Improve invalid UTF-8 lint by finding the expression initializer

This PR introduce a small mechanism to walk up the HIR through bindings, if/else, consts, ... when trying lint on invalid UTF-8.

Fixes rust-lang#115208

…RalfJung

Prevent promotion of const fn calls in inline consts

We don't wanna make that mistake we did for statics and consts worse by letting more code use it.

r? ``@RalfJung``

cc rust-lang#76001

rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const

Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`.

Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all.

However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish...

``@oli-obk`` any ideas?

…lay, r=oli-obk

Call panic_display directly in const_panic_fmt.

`panic_str` just directly calls `panic_display`. The only reason `panic_str` exists, is for a lint to detect an expansion of `panic_2015!(expr)` (which expands to `panic_str`).

It is `panic_display` that is hooked by const-eval, which is the reason we call it here.

Part of rust-lang#116005

r? ``@oli-obk``

…eGomez

Delete obsolete `--disable-per-crate-search` rustdoc flag

This unstable flag is unused by rustdoc since rust-lang@ef96d57.

We should avoid landing this until after rust-lang/docs.rs#2225 is deployed to docs.rs.