Fix `overflowing_literals` lint with repeated negation by theemathas · Pull Request #158302 · rust-lang/rust

theemathas · 2026-06-23T12:05:26Z

This PR consists of: two commits with non-functional cleanups, a commit that adds a test, and a commit that actually changes the behavior. The following description concerns the changed behavior. See the test changed in the fourth commit for code demonstrating the change in behavior.

The overflowing_literal lint is, I believe, supposed to consider the literal and not the surrounding context when deciding whether to lint. This is in contrast to the arithmetic_overflow lint, which only considers code that executes at run time, which excludes the negation inside a literal.

According to the reference, a negation in front of an integer does not result in an overflow. I think of this as: a negation, and only one negation, in front of an integer, is "part of" the integer. Therefore, the overflowing_literal lint should consider that when linting. It should not consider the second or third negation.

Therefore, this PR changes overflowing_literals so that it only lints on 128_i8 when there is no preceding negation at all. This is in contrast to the previous behavior, which lints on 128_i8 preceded by an even number of negations.

This better matches how the argument is actually used. See `rustc_hir::intravisit::{walk_expr,walk_pat_expr}`.

rustbot · 2026-06-23T12:05:30Z

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

rustbot · 2026-06-23T12:05:33Z

r? @adwinwhite

rustbot has assigned @adwinwhite.
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 73 candidates
Random selection from 22 candidates

adwinwhite · 2026-06-27T09:36:40Z

I personally lean towards catching more overflows at compile-time if possible, and we can clarify this in reference instead?

Of course we should hear more opinions. Is starting FCP the right process for that?

theemathas · 2026-06-27T10:57:03Z

If the arithmetic_overflow and overflowing_literal lints are both enabled, then, in my testing, this PR doesn't change what code gets linted. It just changes which lints fire.

I've just noticed that the arithmetic_overflow lint appears to not be firing at all in the ui tests. I'm very confused on why this is happening.

In any case, I'm lang-nominating for opinions on when exactly these two lints should fire.

theemathas · 2026-06-27T11:40:40Z

I figured out that the arithmetic_overflow lint wasn't firing in the tests because compiletest was doing the equivalent of cargo check. So, I edited the test to use --emit link (the equivalent of cargo build), so the lint would fire.

Hopefully it should be obvious from the tests now, that the same amount of overflows are still caught by lints.

theemathas · 2026-06-27T11:43:22Z

Another thing I forgot to mention previously: The run time behavior of an allow(arithmetic_overflow) is a panic in debug mode. In contrast, the run time behavior of an allow(overflowing_literals) is seemingly supposed to be silently overflowing, even in debug mode. This PR makes the lint fire exactly when such silent overflows would otherwise happen.

Fixes rust-lang#158295 The `overflowing_literal` lint is, I believe, supposed to consider the literal and not the surrounding context when deciding whether to lint. This is in contrast to the `arithmetic_overflow` lint, which only considers code that executes at run time, which excludes the negation inside a literal. According to [the reference](https://doc.rust-lang.org/1.96.0/reference/expressions/operator-expr.html#r-expr.operator.int-overflow.unary-neg), a negation in front of an integer does not result in an overflow. I think of this as: a negation, and only one negation, in front of an integer, is "part of" the integer. Therefore, the `overflowing_literal` lint should consider that when linting. It should not consider the second or third negation. Therefore, this commit changes `overflowing_literals` so that it only lints on `128_i8` when there is no preceding negation at all. This is in contrast to the previous behavior, which lints on `128_i8` preceded by an even number of negations.

scottmcm · 2026-07-01T15:31:22Z

I agree with @theemathas's analysis of this. In particular I think the

In contrast, the run time behavior of an allow(overflowing_literals) is seemingly supposed to be silently overflowing, even in debug mode.

note is a good one, and a particularly good reason for it to be deny-by-default and not warn-by-default. (Though it looks like both are currently deny-by-default.)

Not saying (indirectly) that --1 is "a literal" is definitely an improvement, in my mind.

So let's say "yes, for the lint we consider -1 a single literal (since otherwise there's no way to write -128_i8) but further negation is overflow, not part of the literal".

@rfcbot fcp merge lang

(Admittedly the whole thing is a bit weird, since of course -1.exp() isn't a negated literal, but that's not this lint's problem.)

One day I'll remember how to use the bot, sorry

rust-rfcbot · 2026-07-01T15:31:25Z

@scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

traviscross · 2026-07-01T15:35:41Z

Makes sense to me.

@rfcbot reviewed

tmandry · 2026-07-01T15:37:39Z

@rfcbot reviewed

(I believe this is a quality of implementation issue and doesn't need a lang FCP.)

rust-rfcbot · 2026-07-01T15:37:49Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rust-rfcbot · 2026-07-11T15:40:26Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

adwinwhite · 2026-07-15T12:23:12Z

@bors r+ rollup

rust-bors · 2026-07-15T12:23:15Z

📌 Commit 8d254b8 has been approved by adwinwhite

It is now in the queue for this repository.

…uwer Rollup of 8 pull requests Successful merges: - #159197 (Rename ModDefId to ModId and use more) - #159222 (semicolon_in_expressions_from_macros: Lint on non-local macros too) - #159296 (Implement `bool::toggle`) - #158302 (Fix `overflowing_literals` lint with repeated negation) - #158484 (Add documentation for the `cold` and `track_caller` attributes) - #159239 (Add codegen test for remainder match) - #159330 (fix some edition annotations in UI tests) - #159331 (Fix ignore-llvm-version directive in codegen-llvm/array-equality.rs) Failed merges: - #158962 (Add `proc_macro` attribute documentation)

Rollup merge of #158302 - theemathas:neg-lit-lint, r=adwinwhite Fix `overflowing_literals` lint with repeated negation Fixes #158295 This PR consists of: two commits with non-functional cleanups, a commit that adds a test, and a commit that actually changes the behavior. The following description concerns the changed behavior. See the test changed in the fourth commit for code demonstrating the change in behavior. --- The `overflowing_literal` lint is, I believe, supposed to consider the literal and not the surrounding context when deciding whether to lint. This is in contrast to the `arithmetic_overflow` lint, which only considers code that executes at run time, which excludes the negation inside a literal. According to [the reference](https://doc.rust-lang.org/1.96.0/reference/expressions/operator-expr.html#r-expr.operator.int-overflow.unary-neg), a negation in front of an integer does not result in an overflow. I think of this as: a negation, and only one negation, in front of an integer, is "part of" the integer. Therefore, the `overflowing_literal` lint should consider that when linting. It should not consider the second or third negation. Therefore, this PR changes `overflowing_literals` so that it only lints on `128_i8` when there is no preceding negation at all. This is in contrast to the previous behavior, which lints on `128_i8` preceded by an even number of negations.

Rename negated to is_negated_pat.

11c867e

This better matches how the argument is actually used. See `rustc_hir::intravisit::{walk_expr,walk_pat_expr}`.

theemathas added T-lang Relevant to the language team needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. labels Jun 23, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. labels Jun 23, 2026

rustbot assigned adwinwhite Jun 23, 2026

theemathas added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 23, 2026

theemathas added the I-lang-nominated Nominated for discussion during a lang team meeting. label Jun 27, 2026

theemathas force-pushed the neg-lit-lint branch from 9032734 to f76ead3 Compare June 27, 2026 11:38

theemathas added 3 commits June 28, 2026 15:54

Refactor negation handling in TypeLimits lints.

dcac715

Add literal overflow lint test with repeated negations.

dd1bdbb

theemathas force-pushed the neg-lit-lint branch from f76ead3 to 8d254b8 Compare June 28, 2026 08:57

traviscross added the P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang label Jul 1, 2026

rust-lang deleted a comment from rustbot Jul 1, 2026

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jul 1, 2026

rustbot mentioned this pull request Jul 11, 2026

Tracking issue for release notes of #158302: Fix overflowing_literals lint with repeated negation #159137

Open

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 15, 2026

JonathanBrouwer mentioned this pull request Jul 15, 2026

Rollup of 8 pull requests #159336

Merged

traviscross added the waived-reference-pr This language change does not need a Reference PR. label Jul 15, 2026

rust-bors Bot merged commit 68bc4b1 into rust-lang:main Jul 15, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Jul 15, 2026

Uh oh!

Uh oh!

Conversation

theemathas commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 23, 2026

Uh oh!

rustbot commented Jun 23, 2026

Uh oh!

adwinwhite commented Jun 27, 2026

Uh oh!

theemathas commented Jun 27, 2026

Uh oh!

theemathas commented Jun 27, 2026

Uh oh!

theemathas commented Jun 27, 2026

Uh oh!

scottmcm commented Jul 1, 2026

Uh oh!

rust-rfcbot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Jul 1, 2026

Uh oh!

tmandry commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-rfcbot commented Jul 1, 2026

Uh oh!

rust-rfcbot commented Jul 11, 2026

Uh oh!

adwinwhite commented Jul 15, 2026

Uh oh!

rust-bors Bot commented Jul 15, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

theemathas commented Jun 23, 2026 •

edited

Loading

rust-rfcbot commented Jul 1, 2026 •

edited

Loading

tmandry commented Jul 1, 2026 •

edited

Loading