@eddyb @varkor should any ConstKind::Unevaluated be allowed to exist after type check?
This is the cause of https://github.com/rust-lang/rust/issues/70125
I think what happened is: there is a const param, it is monomorphized here. The result is a
ConstKind::Unevaluated. This is normally handled fine when there was no previous monomorphization, but in this case there is a match case missing for unevaluated. I think you can fix this by recursively calling the current function here instead of the if expression.
And just in case replace the
_ wildcard of the match arm with
ConstKind::Param and move the
bug! to a new wildcard arm.
thanks @bjorn3 :heart: will try this out
monomorphize shouldn't leave anything unevaluated, it's pretty much its job, but there's a bug. also, repeatedly applying
monomorphize is wrong, as it will keep substituting, but substitutions can only be meaningfully applied once
Where did I say that repeatedly applying
monomorphize was a good idea?
you suggested recursively calling
which would result in
monomorphize being applied multiple times, potentially
In that case the
monomorphize should not return
ConstKind::Param. I suggested to only apply
anyway special-cases like that should be avoided as much as possible
hence my suggestion to call
monomorphize once (irrespective of variant), and then handle
Unevaluated, in case
monomorphize failed to normalize for whatever reason
That is indeed a much better way. cg_clif also does it that way it seems: https://github.com/bjorn3/rustc_codegen_cranelift/blob/9d014d77813fd28b29d4c3fd166d429274fc94a2/src/constant.rs#L74
monomorphize should be calling eval, it's just that nobody added a
fold_const in the right place :(
I wonder if there's a good way we can force
fold_const to be implemented if
fold_ty has been
@varkor eh we could make them both required or something. idk