Change:
<ins> //@ only-64bit fn main() { format_args!("{}", 0x8f_i8); // issue #115423 //~^ ERROR literal out of range for `i8` format_args!("{}", 0xffff_ffff_u8); // issue #116633 //~^ ERROR literal out of range for `u8` format_args!("{}", 0xffff_ffff_ffff_ffff_ffff_usize); //~^ ERROR literal out of range for `usize` format_args!("{}", 0x8000_0000_0000_0000_isize); //~^ ERROR literal out of range for `isize` format_args!("{}", 0xffff_ffff); // treat unsuffixed literals as i32 //~^ ERROR literal out of range for `i32` } </ins>

Discussion:
No response Error occurs on stable (1.73) and nightly (1.75.0 2023-10-09) Clippy catches this error correctly, but not rustc itself. I had a look at the HIR output and the bug seems to occur when the literal is compile-time formatted to a static str. This erases its type and prevents type checking. Also, this is my first issue, so please let me know if any changes are desired. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Probably a regression caused by the recent change that bakes literals straight into the format string.
This is a duplicate of
ok thanks! Closing as duplicate: also bisection of this issue and of lead to the same group of PRs.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority ().

label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix: