my take on this is that we should always erase lifetimes (not inner late-bound ones though!) in the
ParamEnv when we const-eval anything (and maybe sure to not return a
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.)
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?
say more, why are lifetimes the problem?
though I think I remember adding an
erase_lifetimes step at some point when trying to untangle the current code
they're not, but we don't need to canonicalize them. I remember you yourself hit lifetime inference vars at some point
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
so it's more like the old "freshening"
and we just make layout return a layout error instead of ICE-ing, for those placeholders
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)
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)
which means that even without early normalization, the implementation will have less cases in which it just gives up
I wish I thought of using freshening back when I added all of those cases :/
I can't make a meeting this week
Next week Monday or Friday is OK though.
I'm not able to make a meeting today either; the latter half of next week would work though.
@yodal was the other person involved with const generics.
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
I've been gone from the rustc scene for almost two months now due to work
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. :)
you mean these comments?
I created a new topic but we can pop back to that one :)
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
there are various
unwrap calls from the rests of lifts and things where it's not obvious to me that they make sense
I kind of want to step back and just outline how we think things should be working ideally
ideally we never "fail to lift"
I combined the two zulip topics into one now :P
anyway, I agree we should never fail to lift, because presumably we should be canonicalizing
and for now, I'd prefer to gracefully fail, just like today, if we want to merge something
(note that erasing regions isn't really all that relevant, since they get "normalized" when you canonicalize anyway)
because we're turning user errors into ICEs if we have
that makes sense
yeah I just think it's a waste to canonicalize lifetimes :P
can you give me a sense for when this
try_eval_bits code is going to get called?
it's basically lazy normalization for anything that wants the concrete value of a
usually things that check the length of an array type
which presumably we eventually want
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)
I'm trying to figure out what I want to ask
last time I was digging in this code I felt like:
but it was a bit hard to investigate the latter because the setup was kind of "different"
specifically i'm not sure why
where Foo<SomeType::Item>: Bar is different from
but in any case, maybe I can just outline what I think the intended design is and you can kind of correct me
sorry, got distracted chasing down a few types
in particular I just remembered that one of the things this PR changes is something to do with how
ConstValue works, right?
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.