Don't inline integer literals when they overflow - new attempt

[tstsrt]

Basically #116633 but I implemented the suggested changes.
Fixes #115423. Fixes #116631.

This is my first contribution to this repo so please let me know if I'm supposed to change something :)

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[eggyal]

LGTM

[oli-obk]

I somewhat prefer the approach from #118659 (as it's not duplicating checks we have elsewhere), but I also see @WaffleLapkin's argument that we shouldn't be producing a wrong value if a lint gets allowed. Since the lint seems to be triggering in expanded code, maybe we could forbid within the formatting macro expansion?

[tstsrt]

I agree that #118659 would have been much more elegant if it handled the edge case correctly. But I think this way is still ok because:

1. Only a few types of literals will ever be inlined — at present just strings and integers, and only bools, chars, and floats are left that implement Display
2. Each type needs to be handled differently anyway, so validity checks being performed before inlining is only a small amount of duplicated code.

I don't think it's a good idea to deliberately ignore a user when they disable a lint. Since integer overflow is not undefined behaviour in Rust, it is likely that a user who deliberately allows overflowing literals wants to observe its effect. We should support such cases. The alternative is to make integer literal overflow a hard error instead of a lint. @m-ou-se's comment indicated that this might be what users expect in the first place, but promoting this lint to a hard error might be a bigger breaking change.

Speaking of which, any resolution to this issue will be a breaking change in case anyone is depending on the current behaviour. EDIT: I forgot that the lang team already determined that this is just a bug and should be fixed as normal. Although they spoke about explicitly suffixed literals, but this fix will also make unsuffixed literals larger than i32::MAX also invalid (unless specified). This is consistent with old non-inlined behaviour, but I would like some clarity on the issue..

[oli-obk]

Yea that makes sense

@bors r+

[bors]

📌 Commit 4c8d210 has been approved by oli-obk

It is now in the queue for this repository.