`cc` 1.0.106 removes support for Visual Studio 12. Pin to 1.0.105 so we
don't drop support yet.

Fixes: rust-lang#128722 (comment)

…rithmetic, r=nnethercote

stabilize const_fn_floating_point_arithmetic

Part of rust-lang#128288
Fixes rust-lang#57241

The existing test `tests/ui/consts/const_let_eq_float.rs`  ([link](https:/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.

This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc `@rust-lang/lang`

### Open items

- [x] Update the Reference: rust-lang/reference#1566

…pointer, r=compiler-errors

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc `@rust-lang/lang` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.

…h, r=cjgillot

Retroactively feature gate `ConstArgKind::Path`

This puts the lowering introduced by rust-lang#125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :)

cc rust-lang#129137 `@camelid,` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta.

Fixes rust-lang#128016

Pin `cc` to 1.0.105

`cc` 1.0.106 removes support for Visual Studio 12. Pin to 1.0.105 so we don't drop support yet.

Fixes: rust-lang#128722 (comment)

…acrum

Implement `ptr::fn_addr_eq`

This PR implements rust-lang/libs-team#323: `ptr::fn_addr_eq`.

r? libs

…r-errors

remove invalid `TyCompat` relation for effects

if the current impl uses `Maybe` (`impl const`), the parent impl must use `Maybe` (`impl const`) as well.

I'd like to rename `TyCompat` to `Sub` which is probably clearer. But it would conflict with my other PR.

r? `@rust-lang/project-const-traits`

…ratrieb

panicking: improve hint for Miri's RUST_BACKTRACE behavior

Should help with rust-lang/miri#3838

interpret: ImmTy: tighten sanity checks in offset logic

Also make some debug assertions into assertions. (Will need to be perf'd.)

…-Simulacrum

Add a hack to workaround MSVC CI issues

I'm still attempting to figure out the issue but the failure rate atm seems really high so I'd like to propose an interim hack.

This adds a single delay of 5 minutes, which is absurdly long in CPU time but practically nothing compared to overall CI time.

…times, r=cjgillot

Fix `elided_named_lifetimes` in code

rust-lang#129207 (comment)

r? cjgillot