Fix `overflowing_literals` lint with repeated negation - #158302

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.

Fix `overflowing_literals` lint with repeated negation Fixes rust-lang#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.

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

Pkgsrc changes: * Adapt to changes in vendored crate versions. * Version & checksum changes. Upstream changes: Version 1.99.0 (2026-10-01) ========================== Language -------- - [Add allow-by-default `raw_borrows_via_references` lint that checks for references that decay immediately into raw borrows](rust-lang/rust#138230) - [Extend `unconditional_panic` lint to function calls that panic when the chunks/windows size is zero] (rust-lang/rust#153563) - [Stabilize C-variadic function definitions] (rust-lang/rust#155697) - [Stabilize the ability to use `#[unsafe(naked)]` functions to define C-variadic functions (`#![feature(c_variadic_naked_functions)]`).] (rust-lang/rust#159746) - [Trait methods are now resolved on an adjusted never type (producing a FCW)] (rust-lang/rust#156047) - [Coerce from inference variables to trait objects if the inference variable is related via subtyping to a type that is known to be `Sized`] (rust-lang/rust#157820) - [Stabilize `#[my_macro] mod foo;`] (rust-lang/rust#157857). This allows outlined modules (`mod foo;`) anywhere in the body of a custom attribute or derive macro. - [Fix the `overflowing_literals` lint with repeated negation] (rust-lang/rust#158302). For instance, it will now no longer lint on `--128_i8`, which is already detected by the `arithmetic_overflow` lint. - [Add POSIX symbols to the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints] (rust-lang/rust#158522) - [Lint unused `#[path]` attributes on inline modules] (rust-lang/rust#158835) - [Enable `unreachable_cfg_select_predicates` lint as part of `unused` lint group] (rust-lang/rust#159179) - [Stabilize passing 128-bit integers via vector registers with `asm!` on x86] (rust-lang/rust#159525) - [Explicitly document that some allocations are allowed to grow in-place (but none are allowed to shrink)] (rust-lang/rust#159729) - We now [guarantee] (rust-lang/rust#159730) that the contents of an `UnsafeCell` can be accessed without going through `get` - [The `invalid_reference_casting` lint was adjusted accordingly] (rust-lang/rust#159960) - [Account for globally enabled target features in `global_asm!`] (rust-lang/rust#160594) - [Warn if an invalid `doc` attribute is used on a macro invocation] (rust-lang/rust#161003) Compiler -------- - [Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX] (rust-lang/rust#150732) - [Enable `static_position_independent_executables` on all gnu and musl targets] (rust-lang/rust#158510) - When providing a suggestion about a missing method, rustc now prefers an exactly matching name from a [doc alias attribute] (https://doc.rust-lang.org/rustdoc/advanced-features.html#add-aliases-for-an-item-in-documentation-search) over a similarity search from other method names. If your new users sometimes expect a method under a different name, adding a doc alias will now help them find it via rustc suggestions, in addition to helping them find it via rustdoc search: [When suggesting method names, prefer *exact* doc aliases over similar names](rust-lang/rust#160369) Platform Support ---------------- - [Promote `riscv64-unknown-linux-musl` to Tier 2 with host tools] (rust-lang/rust#158766) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html Libraries --------- - Iteration on `RangeInclusive` (`a..=b` ranges) is now [optimized better in some circumstances] (rust-lang/rust#155114). As a side effect of this, the behavior of `RangeInclusive` values that has already been exhausted (as an iterator) has changed. For example, the return values of `start()` and `end()` on such ranges may return different values, and using such ranges as slice indexes may have different behavior. These behaviors were not guaranteed to be stable, so these changes are considered to not be breaking changes. - [Relax `transmute_copy` to accept `?Sized` types] (rust-lang/rust#155989) - [Update `transmute_copy` to use a non-unwinding panic] (rust-lang/rust#155989) - [Don't escape U+FF9E and U+FF9F in `escape_debug_ext`] (rust-lang/rust#158057) - [Re-export `core::fmt::NumBuffer` in `alloc` (and `std`)] (rust-lang/rust#161430) Stabilized APIs --------------- - [`IntoIterator` for `Box<[T; N]>`] (https://doc.rust-lang.org/stable/std/iter/trait.IntoIterator.html#impl-IntoIterator-for-Box%3C%5BT;+N%5D,+A%3E) - [`IntoIterator` for `&Box<[T; N]>`] (https://doc.rust-lang.org/stable/std/iter/trait.IntoIterator.html#impl-IntoIterator-for-%26Box%3C%5BT;+N%5D,+A%3E) - [`IntoIterator` for `&mut Box<[T; N]>`] (https://doc.rust-lang.org/stable/std/iter/trait.IntoIterator.html#impl-IntoIterator-for-%26mut+Box%3C%5BT;+N%5D,+A%3E) - [`VecDeque::retain_back`] (https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.retain_back) - [`core::ffi::VaList`] (https://doc.rust-lang.org/stable/core/ffi/struct.VaList.html) - [`Box::into_non_null`] (https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#method.into_non_null) - [`Box::from_non_null`] (https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#method.from_non_null) - [`Vec::into_parts`] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.into_parts) - [`Vec::from_parts`] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.from_parts) - [`core::mem::size_of_val_raw`] (https://doc.rust-lang.org/stable/core/mem/fn.size_of_val_raw.html) - [`core::mem::align_of_val_raw`] (https://doc.rust-lang.org/stable/core/mem/fn.align_of_val_raw.html) - [`core::alloc::Layout::for_value_raw`] (https://doc.rust-lang.org/stable/core/alloc/struct.Layout.html#method.for_value_raw) - [`String::from_utf8_lossy_owned`] (https://doc.rust-lang.org/stable/std/string/struct.String.html#method.from_utf8_lossy_owned) - [`string::FromUtf8Error::into_utf8_lossy`] (https://doc.rust-lang.org/stable/std/string/struct.FromUtf8Error.html#method.into_utf8_lossy) - [`FusedIterator for StepBy<I>`] (https://doc.rust-lang.org/stable/std/iter/struct.StepBy.html#impl-FusedIterator-for-StepBy%3CI%3E) - [`std::fs::set_times`] (https://doc.rust-lang.org/stable/std/fs/fn.set_times.html) - [`std::fs::set_times_nofollow`] (https://doc.rust-lang.org/stable/std/fs/fn.set_times_nofollow.html) Cargo ----- - Add a new built-in profile `debug`. This is a preparation for transitioning the `dev` profile away from debugging to give a saner default for faster development iterations. Currently there is no difference between `dev` and `debug` profiles. [docs] (https://doc.rust-lang.org/nightly/cargo/reference/profiles.html#debug-1) [#17214] (rust-lang/cargo#17214) - Workspace members on edition 2024 or later can now override an inherited workspace dependency's `default-features` field. For example, `serde = { workspace = true, default-features = false }` now turns off default features even when the workspace definition enables them. On earlier editions, `default-features = false` is ignored with a warning. ([RFC 3945] (rust-lang/rfcs#3945)) [#17126](rust-lang/cargo#17126) - Incremental compilation is now disabled by default when running in CI. CI is detected via the CI environment variable. [#17220] (rust-lang/cargo#17220) See also the [full Cargo changelog] (https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-199-2026-10-01) Rustdoc ----- - [Add new `unused_footnote_definition` rustdoc lint] (rust-lang/rust#137858) - Smarter filtering of trait impls yields performance improvements of 20% on average and up to 40% on some real-world crates. ([1] (rust-lang/rust#159623), [2](rust-lang/rust#159721), [3](rust-lang/rust#159779), [4](rust-lang/rust#159854), [5](rust-lang/rust#159091)) Compatibility Notes ------------------- - [Fully deprecate the legacy integral modules] (rust-lang/rust#146882). For example, `std::i32::MAX` should be accessed via `i32::MAX` instead. - [Upgrade `no_mangle_generic_items` into hard error] (rust-lang/rust#154585) - [The `Pin::new_unchecked` has had its safety invariants changed slightly] (rust-lang/rust#156935) - [Do not promote references to extern statics] (rust-lang/rust#157641) - [Ensure that the inferred types of `let` patterns typecheck] (rust-lang/rust#157841) - [hermit/fs: Return `unsupported()` instead of `from_raw_os_error(22)`] (rust-lang/rust#158247) - [Fixed a bug where `#[repr(simd)]` was accidentally allowed on macro invocations on stable Rust] (rust-lang/rust#158523) - [Abort const-eval when there are generics in the type of the value being produced] (rust-lang/rust#159504) - [Attributes not applying to anything are now an error in code blocks in doc comments] (rust-lang/rust#159849) - [`Box::leak`: tell people to avoid unleaking] (rust-lang/rust#160323) - [PowerPC inline ASM: Fix scalar floats being in the wrong vector lane on little endian] (rust-lang/rust#160441) - [Do not take `doc(cfg())` into account when filtering doctests] (rust-lang/rust#159014) - [Infer anonymous lifetimes in the types of associated consts as `'static`] (rust-lang/rust#156508) - Macros that expand to a semicolon now produce a warning lint (`semicolon_in_expressions_from_non_local_macros`) even when the macro comes from another crate. Previously, such warnings only appeared for macros from the same crate, to avoid showing warnings that can't be fixed locally; however, this masked problems, as integration tests from the crate providing the macro get compiled as a separate crate, so tests often wouldn't reveal this issue. If you encounter a lint like this, please make sure to report it to the crate providing the macro so they can fix it; don't just silence it in your own crate. - [`semicolon_in_expressions_from_macros`: Lint on non-local macros too] (rust-lang/rust#159222) - [Split non-local `semicolon_in_expressions_from_macros` into a separate lint] (rust-lang/rust#159700) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Update to LLVM 23] (rust-lang/rust#158734)

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

theemathas deleted the neg-lit-lint branch July 16, 2026 00:33

BoxyUwU mentioned this pull request Sep 4, 2026

Draft release notes for 1.99.0 #162306

Closed

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