Fix ICE when a suffixed literal's type doesn't match the expected const arg type

[lapla-cogito]

close #152653
close #152962

const_lit_matches_ty() ignored literal suffixes - e.g. LitKind::Int(..) discarded the LitIntType and ty::Uint(_) matched any unsigned type, so 0u8 was accepted for usize. This let the try_lower_anon_const_lit() fast path produce a mistyped ty::Const::Value, causing an ICE in MIR const propagation.

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 68 candidates
• Random selection from 15 candidates

[lapla-cogito]

This was required to perform MIR analysis.

[lqd]

Do you mean forcing codegen? If so check out the build-fail directive.

[lapla-cogito]

Do you mean forcing codegen?

No, this ICE occurs when rustc reaches the MIR analysis stage despite the presence of type errors. I think the build-fail directive is inappropriate here because, IIUC, it first requires the check pass to succeed. However, this test contains type errors that cause the check pass to fail, so compiletest aborts the test before ever reaching the full build where the ICE would occur.

[lapla-cogito]

This fix, as mentioned above, fixes the ICE while simultaneously reverting the seemingly redundant error output introduced in #152001 (in fact, this ICE was identified as originating from this PR in the original issue).

[Kivooeo]

r? BoxyUwU

[rustbot]

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

[lapla-cogito]

This change also fixes the newly reported issue #152962, so I’ve added a test for it.

[BoxyUwU]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[lapla-cogito]

@rustbot ready

[BoxyUwU]

this looks good to me though im unsure how this overlaps with #153075 as that will change what type const FOO: usize = 10_u8; lowers to which might affect the tests or introduce similar ICEs as what you're fixing here 🤔

I would expect that there's a more fundamental problem here that some part of the compiler isnt expecting for a type const to normalize to something of an incorrect type. I don't think the right way to fix that is in HIR ty lowering instead we probably need to be doing error tainting better somewhere but I don't fully understand what's actually going wrong and where 🤔

We certainly want const_lit_matches_ty to behave correctly though- (which it was not before this PR)

[lapla-cogito]

Looking at #153075, I understand that literals will be handled as ConstArgKind::Literal (MgcaDisambiguation::Direct) instead of AnonConst, which means they will go through lower_const_arg_literal() rather than const_lit_matches_ty() via try_lower_anon_const_lit(). This means the same ICE could occur through a different path. Given that, I think there are the following options (though I'm not sure how much should be addressed in this PR 😵 ):

• Add a const_lit_matches_ty() check in lower_const_arg_literal as well
• Have lit_to_const() itself detect the mismatch between the suffixed literal's type and the expected type — this would also fix the ICE
• Taint type-mismatched consts as errors, as Boxy suggests

I'd also be happy to merge the current fix as-is (with an updated commit message and with the tests added in this PR removed, since it would no longer prevent the ICE once #153075 lands) and address the deeper issue in a follow-up PR.

[rust-bors]

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