Fix ICE when trying to convert ConstKind::Error to usize

[syvb]

Fixes an ICE (#113021) caused by trying to convert a ConstKind::Error to a usize.

Instead of panicking in the call to eval_target_usize in prefix_slice_suffix, prefix_slice_suffix now bails and does nothing. If it sees a ConstKind::Error, then there has already been an error reported so not doing anything shouldn't be a problem.

Closes #113021.

r? @matthiaskrgr

[BoxyUwU]

r? @BoxyUwU

please remove the first 5 commits

[cjgillot]

Why is this code path even reached? If there is an error in the constant, the typeck results or THIR should be tainted, and MIR building should not happen. Any idea why this does not happen?

[syvb]

@cjgillot I bisected this (#113021 (comment)), and this ICE was probably caused by #99798 (which added ConstKind::Expr), but I'm not sure how exactly that PR caused the ICE.

[wesleywiser]

I think @cjgillot is correct and MIR building shouldn't be running at all. The change is this PR is ok but I don't really understand why we should have to add it here (and if this we do need this here for some reason, there are probably other areas that will need similar treatment).

r? @cjgillot

[oli-obk]

r? @oli-obk
I was recently digging around in similar issues. We have lots of similar issues lurking just behind convenient query orderings.

You can use -Ztreat-err-as-bug to find the query backtrace of the original error and then check if there's a place in there where we can taint typeck or thir building to avoid mir building.

[oli-obk]

closing in favor of #117046