-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
overflowing_literals
should have an option for "ignore signed overflows"
#99195
Comments
edit: see #108383 instead |
The big complication to me here is that context can be really important for whether the overflow is "important". For example, what does this do? fn main() {
for i in 100..200 {
foo(i);
dbg!(i);
}
} It might be nothing, depending on non-local stuff: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4f71666663951eb0bcfa3accb2593a5d. And I'm not sure that signed-vs-unsigned is quite the right pivot here. After all, A first stab at trying to tease out the various categories:
I'll nominate to see if lang has any suggestions on whether this should be split up at all, or if so how. (Coming up again because of #108269.) |
My preference is that, in a future edition, all overflowing literals are unconditionally hard errors that can't be changed by some lint. This is how it should have always been, its just some sloppy left over from other languages. |
As @BoxyUwU noted to me, we have to combine the hyphen-minus and the digits, at least when evaluating this lint, as otherwise we can't resolve this correctly: let x: i8 = -128; Given first 128, and then negation, it would first overflow. To the correct value, yes! And the negation would do nothing. But it would definitely trigger our linting otherwise. |
We discussed this briefly in some lang meetings. The temperature of the room was positive towards potentially tweaking things, but would be interested in having a concrete proposal to review before saying more. |
Just double-checking on what the process is here, is there somewhere where that proposal would best go besides Zulip or here? Not sure what lang-team does nowadays for this. |
@clarfonthey I would recommend posting a concrete proposal here on the issue, forking the discussion itself off into a Zulip thread, and coming back here with a summary of any revisions. I seem to remember lang had been experimenting with the "major change proposal" format, but I'm not sure if they've continued use of it into 2023: https://github.com/rust-lang/lang-team/issues?q=is%3Aissue+label%3Amajor-change |
Since lints aren't part of the strict stability promise, we can definitely use low-overhead processes here. Do whatever's easiest for now, and we can figure out how to officialize it as needed. |
Sounds good to me! Mostly just curious what the best way would be to ensure that folks are actually able to chime in on the design, since I know that not everyone is following this specific thread. I'll probably just post a link on Zulip if/when I end up writing a proposal, assuming someone else doesn't beat me to it. |
I have recently been working with code where using the two's complement form of signed literals is useful, but this doesn't mesh very well with the
overflowing_literals
lint.Here's a simplified example:
Right now, with the
overflowing_literals
lint,good_signed
,bad_signed
, andbad_unsigned
will all be marked as overflowing. To avoidgood_signed
being marked as invalid, I had code that I blanket marked as#[allow(overflowing_literals)]
, but this caused me to miss literals likebad_signed
andbad_unsigned
, which overflow regardless of their sign.I'm not sure what the best strategy here is. I see two possible solutions:
overflowing_literals
lint is split into a separate lint alongsideoverflowing_literals
lint, where this new lint warns on integer literals that would not overflow if they were unsigned, but do overflow because they're signed. This can be selectively allowed in code while still being able to keep theoverflowing_literals
lint on.Either way, the current configuration of the lint seems overly restrictive.
After searching, I decided to file a separate issue instead of including this analysis in #53628. If this is seen as too similar to the existing ticket, I'm fine with also closing this in favour of that one.
The text was updated successfully, but these errors were encountered: