Stream: t-compiler/help

Topic: Unevaluated constants

ange (Jan 31 2019 at 14:56, on Zulip):

At which point Unevaluated constants supposed to get evaluated away? I've added some debug!() calls and it seems the same constant (an array length) is handled in AssociatedTypeNormalizer::fold_const... 13 times. Which leads me to believe that the resulting Evaluated value does not replace the original Unevaluated one :-)

oli (Jan 31 2019 at 15:19, on Zulip):

is the fold_const called on the same constant many times or is the Unevaluated branch in fold_const hit many times?

ange (Jan 31 2019 at 15:28, on Zulip):

@Oli afaict, it's both. I get the debug output from both right inside the if let ty::LazyConst::Unevaluated and a debug!() call that prints out the result of tcx.intern_lazy_const(). I used sort -u to verify that it's always handling the same constant, fwiw

oli (Jan 31 2019 at 15:29, on Zulip):

oh, that is not good, can you open an issue with a repro?

ange (Jan 31 2019 at 15:31, on Zulip):

@Oli an issue already exists :-) I'm simply using it as an excuse to dive into rustc, which is why I'm asking for guidance on whether this is supposed to happen or not

oli (Jan 31 2019 at 15:36, on Zulip):

Oh wow. You went from looking at an ICE to finding this issue

oli (Jan 31 2019 at 15:36, on Zulip):


ange (Jan 31 2019 at 15:38, on Zulip):

well, it I was tracking the constant that ends up being unevaluated during qualify_consts

oli (Jan 31 2019 at 15:39, on Zulip):

I'm assuming the constant is part of a TyArray?

ange (Jan 31 2019 at 15:41, on Zulip):


oli (Jan 31 2019 at 15:43, on Zulip):

So we can basically assume that it's the Self's fault. I'm guessing we have the Self type somewhere, resolve it to [T; Unevaluated] then compute the Unevaluated and kinda throw the resolved type away

ange (Jan 31 2019 at 15:45, on Zulip):

Yah, it does get resolved to [T; Unevaluated], where the Unevaluated value will always be evaluated to the correct result (i.e. bits 30, u8)

oli (Jan 31 2019 at 15:45, on Zulip):

The next step would be to figure out if that is true and whether we can make the type folders produce the resolved types

oli (Jan 31 2019 at 15:45, on Zulip):

do you know where the Self resolving happens?

ange (Jan 31 2019 at 15:45, on Zulip):

nope, searched far and wide for that but eventually timed out and focused on the actual issue

ange (Jan 31 2019 at 15:46, on Zulip):

(I mean, given that apparently it does get resolved properly)

ange (Jan 31 2019 at 16:07, on Zulip):

looking at the set of backtraces to figure out which evaluation is supposed to commit the result, but unlikely that I'll figure this out before I have to start packing for fosdem

oli (Jan 31 2019 at 16:10, on Zulip):

Yea, I am not finding it either

oli (Jan 31 2019 at 16:12, on Zulip):

uh wait. how are you comparing the unevaluated constants?

oli (Jan 31 2019 at 16:13, on Zulip):

maybe they are just equal but not the same

ange (Jan 31 2019 at 16:17, on Zulip):

@Oli, I'm comparing { def: Item(DefId(0/1:10 ~ iceme[317d]::main[0]::{{constant}}[0])), substs: [] } (i.e. ty::Instance umm, instances)

oli (Jan 31 2019 at 16:27, on Zulip):

@ange the thing is, while the constants are the same, they are duplicated in multiple places before we ever try to const eval them. I think you are just seeing this duplication

oli (Jan 31 2019 at 16:28, on Zulip):

Now... array lengths are actually quite trivial right now, so we could just always evaluate them right at the creation time, but I think that would but us in a bind in the future

ange (Jan 31 2019 at 16:29, on Zulip):

@Oli ok great. I'll try to understand this duplication and why it happens then

ange (Jan 31 2019 at 16:30, on Zulip):

yah I guess constant evaluation should be happening at the point where every constant expression that can eventually be evaluated, can be evaluated

ange (Jan 31 2019 at 16:30, on Zulip):

(still not sure what that point is though, per my original question)

Last update: Sep 18 2020 at 20:30UTC