Stream: t-compiler/const-eval

Topic: constants, canonicalization, and normalization oh my!


nikomatsakis (May 07 2019 at 16:14, on Zulip):

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. =)

nikomatsakis (May 07 2019 at 16:30, on Zulip):

Presumably constant evaluation doesn't really care about lifetimes

nikomatsakis (May 07 2019 at 16:31, on Zulip):

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.

nikomatsakis (May 07 2019 at 16:31, on Zulip):

(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)

eddyb (May 07 2019 at 16:48, on Zulip):

@nikomatsakis I was hoping we could give miri the canonical form

eddyb (May 07 2019 at 16:48, on Zulip):

not run miri inside an inference context

eddyb (May 07 2019 at 16:48, on Zulip):

but as if the inference variables were parameters in scope

eddyb (May 07 2019 at 16:49, on Zulip):

it can't advance inference, but it can "polymorphically evaluate" in some cases

nikomatsakis (May 07 2019 at 16:57, on Zulip):

I was hoping we could give miri the canonical form

this is exactly what I had in mind, @eddyb

nikomatsakis (May 07 2019 at 16:58, on Zulip):

I mean this should basically "just work", presuming miri can cope with the presence of canonical vars

eddyb (May 07 2019 at 17:00, on Zulip):

miri doesn't really look at types ;)

eddyb (May 07 2019 at 17:00, on Zulip):

with minor exceptions

eddyb (May 07 2019 at 17:01, on Zulip):

@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

nikomatsakis (May 07 2019 at 17:02, on Zulip):

OK. I am right now doing a quick hack to try and unblock my investigations -- namely, erasing the regions before invoking lift

nikomatsakis (May 07 2019 at 17:02, on Zulip):

but I could take a look at introducing the canonicalizations, or point @oli in the right direction

eddyb (May 07 2019 at 17:02, on Zulip):

oh, regions, lol

eddyb (May 07 2019 at 17:02, on Zulip):

we should always erase regions and recover them in the type

nikomatsakis (May 07 2019 at 17:02, on Zulip):

Something still feels "funny" to me about how we are doing normalization here

eddyb (May 07 2019 at 17:02, on Zulip):

did I not do that already?

eddyb (May 07 2019 at 17:03, on Zulip):

miri shouldn't see unerased regions, they should only exist on the "user side" of const-eval, not inside the query

nikomatsakis (May 07 2019 at 17:03, on Zulip):

You did not, but that quick hack doesn't get me that far

nikomatsakis (May 07 2019 at 17:03, on Zulip):

error: internal compiler error: src/librustc/traits/project.rs:415: failed to lift [ReErased, ReErased, _, _] to global

eddyb (May 07 2019 at 17:03, on Zulip):

but I may have been overly cautious

eddyb (May 07 2019 at 17:04, on Zulip):

when I was talking about canonicalization, I've been referring to const/type inference variables all along, not lifetimes

eddyb (May 07 2019 at 17:04, on Zulip):

yes, that's what you need to canonicalize

eddyb (May 07 2019 at 17:06, on Zulip):

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"

nikomatsakis (May 07 2019 at 17:07, on Zulip):

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.

nikomatsakis (May 07 2019 at 17:07, on Zulip):

anyway, that's off topic :)

eddyb (May 07 2019 at 17:07, on Zulip):

@nikomatsakis btw, you need to be very careful if you've erased lifetimes

davidtwco (May 07 2019 at 17:07, on Zulip):

ugh, I've been meaning to get back to that.

eddyb (May 07 2019 at 17:08, on Zulip):

to make sure there are no lifetimes in the value itself, and to use the old type

eddyb (May 07 2019 at 17:16, on Zulip):

so none of the erasure leaks back into whatever wanted to normalize the const

nikomatsakis (May 07 2019 at 17:29, on Zulip):

yeah -- so -- actually I think there is a simpler hack to get me past my immediate problems, but it may fail down the line

Last update: Nov 15 2019 at 21:10UTC