In c2rust_instrument::into_operand::make_const, use `ConstantKind::…

…from_bits`, not `ty::Const::from_bits`, since the latter requires `ConstantKind::Ty`.

When using `ConstantKind::Ty` explicitly, it tells `rustc` that the constant is coming from the type system.
This is not the case for our `u32` indices that have nothing to do with the type system (e.x. a const generic parameter).
A change in `nightly-2022-09-19` reworked the constant evaluator
and requires such `ConstantKind::Ty`s to use `ConstKind::Param` (e.x. a const generic parameter),
but `ty::Const::from_bits` uses `ConstKind::Value`, and thus there is a runtime crash.
Thus, now we switch to using `ConstantKind::from_bits` directly,
which lets the `rustc` code choose the correct `ConstantKind` (in practice, `ConstantKind::Val`),
which avoids the `ConstKind::Param` runtime check.

Although this change arose from a crash due to additions in `nightly-2022-09-19`,
I'm including it as a separate commit before that
because it appears we were using `ConstantKind::Ty` wrong the whole time,
and this recent change just added more stirngent checks and exposed our error.

dynamic_instrumentation/src/into_operand.rs

@@ -1,6 +1,6 @@
 use rustc_middle::{
     mir::{Constant, ConstantKind, Local, Operand, Place},
-    ty::{self, ParamEnv, TyCtxt},
+    ty::{ParamEnv, TyCtxt},
 };
 use rustc_span::DUMMY_SP;
 
@@ -37,10 +37,6 @@ fn make_const(tcx: TyCtxt, idx: u32) -> Operand {
     Operand::Constant(Box::new(Constant {
         span: DUMMY_SP,
         user_ty: None,
-        literal: ConstantKind::Ty(ty::Const::from_bits(
-            tcx,
-            idx.into(),
-            ParamEnv::empty().and(tcx.types.u32),
-        )),
+        literal: ConstantKind::from_bits(tcx, idx.into(), ParamEnv::empty().and(tcx.types.u32)),
     }))
 }