Stream: t-compiler

Topic: discuss constants and normalization


eddyb (Jul 12 2019 at 10:57, on Zulip):

my take on this is that we should always erase lifetimes (not inner late-bound ones though!) in the Substs/ParamEnv when we const-eval anything (and maybe sure to not return a Ty/Substs from const-eval, so the user is forced to reuse the original type to make a ty::Const and doesn't risk losing information etc.)

nikomatsakis (Jul 12 2019 at 10:57, on Zulip):

ok I added an event to help me remember :) maybe @oli, @varkor, or others will be able to make it, but maybe not? I forget -- there was one other person working on the const generics PR -- but I forgot their name?

nikomatsakis (Jul 12 2019 at 10:57, on Zulip):

say more, why are lifetimes the problem?

nikomatsakis (Jul 12 2019 at 10:58, on Zulip):

though I think I remember adding an erase_lifetimes step at some point when trying to untangle the current code

eddyb (Jul 12 2019 at 10:58, on Zulip):

they're not, but we don't need to canonicalize them. I remember you yourself hit lifetime inference vars at some point

eddyb (Jul 12 2019 at 10:59, on Zulip):

and for type/const infer vars, we can canonicalize but it doesn't have to be a proper canonicalization query because there is no inference going on in miri and it would just rely on placeholders as opaque things

eddyb (Jul 12 2019 at 11:00, on Zulip):

so it's more like the old "freshening"

eddyb (Jul 12 2019 at 11:00, on Zulip):

and we just make layout return a layout error instead of ICE-ing, for those placeholders

eddyb (Jul 12 2019 at 11:01, on Zulip):

so some things will fail (if they need further inference to progress) while others will work just fine (e.g. parameters in scope that aren't used by the constant MIR itself, but were instantiated with inference vars)

eddyb (Jul 12 2019 at 11:02, on Zulip):

and that should be enough to handle everything without disallowing ty::Consts that used to fail "lift_to_global" (i.e. that contain inference vars)

eddyb (Jul 12 2019 at 11:03, on Zulip):

which means that even without early normalization, the implementation will have less cases in which it just gives up

eddyb (Jul 12 2019 at 11:03, on Zulip):

I wish I thought of using freshening back when I added all of those cases :/

oli (Jul 12 2019 at 11:50, on Zulip):

I can't make a meeting this week

oli (Jul 12 2019 at 11:51, on Zulip):

Next week Monday or Friday is OK though.

varkor (Jul 12 2019 at 12:26, on Zulip):

I'm not able to make a meeting today either; the latter half of next week would work though.

varkor (Jul 12 2019 at 12:26, on Zulip):

@yodal was the other person involved with const generics.

yodal (Jul 12 2019 at 12:42, on Zulip):

I can try to make it to any meeting, but I can make no promises and I don't know how much input I will be able to provide

yodal (Jul 12 2019 at 12:42, on Zulip):

I've been gone from the rustc scene for almost two months now due to work

nikomatsakis (Jul 12 2019 at 13:58, on Zulip):

Well @eddyb even if the others aren't around, do you want to talk about constants and normalization? I'd be happy to schedule a time to chat when others can't make it, too, but also happy to discuss a bit beforehand. :)

eddyb (Jul 12 2019 at 13:59, on Zulip):

sure

eddyb (Jul 12 2019 at 13:59, on Zulip):

(deleted)

nikomatsakis (Jul 12 2019 at 13:59, on Zulip):

you mean these comments?

nikomatsakis (Jul 12 2019 at 13:59, on Zulip):

I created a new topic but we can pop back to that one :)

nikomatsakis (Jul 12 2019 at 14:00, on Zulip):

hi @eddyb

nikomatsakis (Jul 12 2019 at 14:01, on Zulip):

I'm not 100% sure where I'd like to start but -- to refresh my memory -- #59369 basically tries to evaluate constants when it would otherwise error

nikomatsakis (Jul 12 2019 at 14:03, on Zulip):

there are various unwrap calls from the rests of lifts and things where it's not obvious to me that they make sense

nikomatsakis (Jul 12 2019 at 14:03, on Zulip):

I kind of want to step back and just outline how we think things should be working ideally

eddyb (Jul 12 2019 at 14:03, on Zulip):

(deleted)

eddyb (Jul 12 2019 at 14:04, on Zulip):

ideally we never "fail to lift"

nikomatsakis (Jul 12 2019 at 14:04, on Zulip):

ok

nikomatsakis (Jul 12 2019 at 14:04, on Zulip):

I combined the two zulip topics into one now :P

nikomatsakis (Jul 12 2019 at 14:05, on Zulip):

anyway, I agree we should never fail to lift, because presumably we should be canonicalizing

eddyb (Jul 12 2019 at 14:05, on Zulip):

and for now, I'd prefer to gracefully fail, just like today, if we want to merge something

nikomatsakis (Jul 12 2019 at 14:05, on Zulip):

(note that erasing regions isn't really all that relevant, since they get "normalized" when you canonicalize anyway)

eddyb (Jul 12 2019 at 14:05, on Zulip):

because we're turning user errors into ICEs if we have .unwrap() there

nikomatsakis (Jul 12 2019 at 14:06, on Zulip):

that makes sense

eddyb (Jul 12 2019 at 14:06, on Zulip):

yeah I just think it's a waste to canonicalize lifetimes :P

nikomatsakis (Jul 12 2019 at 14:06, on Zulip):

can you give me a sense for when this try_eval_bits code is going to get called?

eddyb (Jul 12 2019 at 14:06, on Zulip):

it's basically lazy normalization for anything that wants the concrete value of a ty::Const

eddyb (Jul 12 2019 at 14:06, on Zulip):

usually things that check the length of an array type

nikomatsakis (Jul 12 2019 at 14:07, on Zulip):

which presumably we eventually want

eddyb (Jul 12 2019 at 14:07, on Zulip):

like layout (which needs to report a layout error, not ICE) or various checks that special-case 0 (which can be conservative if the value is unknown)

nikomatsakis (Jul 12 2019 at 14:07, on Zulip):

right, ok

nikomatsakis (Jul 12 2019 at 14:09, on Zulip):

I'm trying to figure out what I want to ask

nikomatsakis (Jul 12 2019 at 14:11, on Zulip):

last time I was digging in this code I felt like:

nikomatsakis (Jul 12 2019 at 14:11, on Zulip):

but it was a bit hard to investigate the latter because the setup was kind of "different"

nikomatsakis (Jul 12 2019 at 14:12, on Zulip):

specifically i'm not sure why where Foo<SomeType::Item>: Bar is different from [T; SomeConstant]

nikomatsakis (Jul 12 2019 at 14:12, on Zulip):

but in any case, maybe I can just outline what I think the intended design is and you can kind of correct me

nikomatsakis (Jul 12 2019 at 14:14, on Zulip):

sorry, got distracted chasing down a few types

nikomatsakis (Jul 12 2019 at 14:15, on Zulip):

in particular I just remembered that one of the things this PR changes is something to do with how ConstValue works, right?

nikomatsakis (Jul 12 2019 at 14:16, on Zulip):

ok, well, given that @oli and others can't attend -- perhaps we can schedule another time to dig, and I'll read into the code in the meantime. @eddyb I'm going to reassign that PR to you for review, I think I am fine with it, if I understand what's going on.

Last update: Nov 22 2019 at 05:50UTC