unwrap_usize should at least try to evaluate the underlying constant

[oli-obk]

r? @eddyb

fixes#59016

I know that I'm still using ParamEnv wrongly, but that's a preexisting issue not amplified by this PR.

[oli-obk]

cc @nikomatsakis this is related to lazy normalization. I could probably run the regular opportunistic normalization on the types (and thus the array lengths inside the array types) obtained in

rust/src/librustc_typeck/check/_match.rs

Line 396 in ad8a3eb

let expected_ty = self.structurally_resolved_type(pat.span, expected);

but I'm not sure if we'd ever catch all the cases (the linked issue shows other similar ICEs)

[oli-obk]

@eddyb is 1650513 what you had in mind?

[eddyb]

I was thinking of tcx.lift_to_global(&substs).unwrap(), but it makes sense if the type also contains inference variables...
The code is confusing, maybe split the ParamEnvAnd before doing anything to it?

But really, you're calling .unwrap_or_else(|| bug!(...)) - my point was to not panic in those cases, but rather... I don't even know what's happening anymore :(

Your error says this is what can't be lifted:

ParamEnvAnd{ param_env:ParamEnv{
caller_bounds:[Binder(OutlivesPredicate('_#0r,'_#1r
))],
reveal:UserFacing,
def_id:None},
value: usize
}

But this can't really exist? Ohhh, you need to convert it to a RevealAllParamEnv and then call .and(ty) on it, to pass it to layout_of. That will clear all the irrelevant bounds!

[bors]

☔ The latest upstream changes (presumably #59636) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #59612) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC-zz]

ping from triage @eddyb waiting for your review on this

[oli-obk]

Nope, I still have things to address, sorry about that

[eddyb]

This is also waiting on @nikomatsakis for a few questions.

[pnkfelix]

cc #60471 since this is "related to lazy normalization"

[oli-obk]

@nikomatsakis this is ready for review again.

The big question related to lazy normalization is whether it's ok that this evalutes (some) constants at the point where someone is trying to act upon the actual value of the constant.

Eager normalization happens in

rust/src/librustc/traits/project.rs

Line 401 in 999c1fc

fnfold_const(&mutself,constant:&'tcx ty::Const<'tcx>) -> &'tcx ty::Const<'tcx>{

and

rust/src/librustc/traits/query/normalize.rs

Line 191 in 5cd2806

fnfold_const(&mutself,constant:&'tcx ty::Const<'tcx>) -> &'tcx ty::Const<'tcx>{

EDIT for clarity: this PR does not change eager normalization. We just do lazy normalization of some constants that were never eagerly normalized.

[eddyb]

@oli-obk I would expect that for now eager normalization would still resolve at least everything which evaluates successfully, right?
I mean, that is the case for associated type projections, I don't see why consts would be different.

[bors]

☔ The latest upstream changes (presumably #59276) made this pull request unmergeable. Please resolve the merge conflicts.

[wirelessringo]

Ping from triage, @eddyb@Centril any updates on this? Thanks

[oli-obk]

@bors r=eddyb,nikomatsakis

[bors]

📌 Commit bd57498 has been approved by eddyb,nikomatsakis

[bors]

⌛ Testing commit bd57498 with merge c471519...

[bors]

☀️ Test successful - checks-azure
Approved by: eddyb,nikomatsakis
Pushing c471519 to master...