So I have been looking into what exactly goes wrong when we try to have constant evaluation done "correctly". After discussing with @eddyb, I modified the "parent" of inline constants so that they inherit from their environment. I immediately started hitting problems with this code in
project.rs. Specifically it fails on this line:
let substs = tcx.lift_to_global(&substs).unwrap();
because the lift fails. I've then been skimming @oli's PR #59369, which I don't really follow in its entirety, but I see talks about canonicalization.
I wanted to try and help out in figuring out what the right thing to do is here. =)
Presumably constant evaluation doesn't really care about lifetimes
But what would happen if it encountered an "inference variable" -- is it prepared for that? I guess this could happen if you had generic constants, at least in some circumstances.
(This reminds me that I also wanted to talk over the const generics strategy with @varkor; I guess I don't have a tight mental model for what the "distinct pieces" are here)
@nikomatsakis I was hoping we could give miri the canonical form
not run miri inside an inference context
but as if the inference variables were parameters in scope
it can't advance inference, but it can "polymorphically evaluate" in some cases
I was hoping we could give miri the canonical form
this is exactly what I had in mind, @eddyb
I mean this should basically "just work", presuming miri can cope with the presence of canonical vars
miri doesn't really look at types ;)
with minor exceptions
@nikomatsakis it's likely that the only thing you need to do is move whatever category of type in question to this match arm: https://github.com/rust-lang/rust/blob/f5371a5ac7a9ef4446d46e7c8a2523e56f7a7900/src/librustc/ty/layout.rs#L1229
OK. I am right now doing a quick hack to try and unblock my investigations -- namely, erasing the regions before invoking
but I could take a look at introducing the canonicalizations, or point @oli in the right direction
oh, regions, lol
we should always erase regions and recover them in the type
Something still feels "funny" to me about how we are doing normalization here
did I not do that already?
miri shouldn't see unerased regions, they should only exist on the "user side" of const-eval, not inside the query
You did not, but that quick hack doesn't get me that far
error: internal compiler error: src/librustc/traits/project.rs:415: failed to lift [ReErased, ReErased, _, _] to global
but I may have been overly cautious
when I was talking about canonicalization, I've been referring to const/type inference variables all along, not lifetimes
yes, that's what you need to canonicalize
btw, having non-
ty::Param "type variables" in codegen, which
ty::layout treats the same as type parameters, is the way I think we should do both
DispatchFromDyn (although there you arguably can have a
ty::Param?) and "polymorphization"
re: polymorphization, I sort of forgot that @davidtwco and I were doing investigations there, trying to get a figure on what kind of improvements we could expect. Our prelim results were "not much" but we didn't really get that far.
anyway, that's off topic :)
@nikomatsakis btw, you need to be very careful if you've erased lifetimes
ugh, I've been meaning to get back to that.
to make sure there are no lifetimes in the value itself, and to use the old type
so none of the erasure leaks back into whatever wanted to normalize the const
yeah -- so -- actually I think there is a simpler hack to get me past my immediate problems, but it may fail down the line