Stream: t-compiler/help

Topic: ConstKind::Unevaluated after typecheck


Bastian Kauschke (Mar 21 2020 at 19:31, on Zulip):

@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

bjorn3 (Mar 21 2020 at 20:10, on Zulip):

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.

bjorn3 (Mar 21 2020 at 20:12, on Zulip):

And just in case replace the _ wildcard of the match arm with ConstKind::Param and move the bug! to a new wildcard arm.

Bastian Kauschke (Mar 21 2020 at 20:42, on Zulip):

thanks @bjorn3 :heart: will try this out

eddyb (Mar 22 2020 at 20:49, on Zulip):

@bjorn3 ftr, 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

bjorn3 (Mar 22 2020 at 20:51, on Zulip):

Where did I say that repeatedly applying monomorphize was a good idea?

eddyb (Mar 22 2020 at 20:52, on Zulip):

you suggested recursively calling eval_mir_constant

eddyb (Mar 22 2020 at 20:52, on Zulip):

after this monomorphize call https://github.com/rust-lang/rust/blob/46f5aa93d47e9077775ad9038970fd4c77abaad7/src/librustc_codegen_ssa/mir/constant.rs#L61

eddyb (Mar 22 2020 at 20:53, on Zulip):

which would result in monomorphize being applied multiple times, potentially

bjorn3 (Mar 22 2020 at 20:54, on Zulip):

In that case the monomorphize should not return ConstKind::Param. I suggested to only apply monomorphize on ConstKind::Param.

eddyb (Mar 22 2020 at 20:55, on Zulip):

anyway special-cases like that should be avoided as much as possible

eddyb (Mar 22 2020 at 20:55, on Zulip):

hence my suggestion to call monomorphize once (irrespective of variant), and then handle Unevaluated, in case monomorphize failed to normalize for whatever reason

bjorn3 (Mar 22 2020 at 20:57, on Zulip):

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

eddyb (Mar 22 2020 at 21:00, on Zulip):

monomorphize should be calling eval, it's just that nobody added a fold_const in the right place :(

varkor (Mar 23 2020 at 16:10, on Zulip):

I wonder if there's a good way we can force fold_const to be implemented if fold_ty has been

eddyb (Mar 23 2020 at 16:35, on Zulip):

@varkor eh we could make them both required or something. idk

Last update: Apr 03 2020 at 18:10UTC