Fix FP in default_numeric_fallback when type is context-constrained#16908
Open
BootstrapperSBL wants to merge 1 commit intorust-lang:masterfrom
Open
Fix FP in default_numeric_fallback when type is context-constrained#16908BootstrapperSBL wants to merge 1 commit intorust-lang:masterfrom
default_numeric_fallback when type is context-constrained#16908BootstrapperSBL wants to merge 1 commit intorust-lang:masterfrom
Conversation
Previously the lint flagged any unsuffixed numeric literal whose resolved type was the fallback type (`i32` / `f64`) without checking whether the type was actually picked by fallback. In `let _ = a + 3;` where `a: i32`, the literal `3` is `i32` because the binary operator forces both operands to share a type, not because of fallback, so no warning should fire. Handle `ExprKind::Binary` in the visitor: for operators that require both operands to share a type (everything except shifts), if the sibling operand has a concrete numeric type that came from a non- (unsuffixed-literal) source, push an `ExplicitTyBound(true)` while visiting the other operand. Outer bounds propagate downward so nested arithmetic like `a + 1 + 2` is also recognised as constrained. Shifts are intentionally skipped because `<<` and `>>` allow each side to have its own integer type, so a typed RHS does not constrain the LHS. fixes rust-lang#16745
Collaborator
|
r? @dswij rustbot has assigned @dswij. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Collaborator
|
|
Lintcheck changes for 9ada8b9
This comment will be updated if you push new changes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fixes #16745
clippy::default_numeric_fallbackwas flagging numeric literals whose resolved type happened to bei32/f64, even when that type was forced by a typed neighbor in a binary expression rather than by fallback.Before
After
The above no longer warns. The lint now treats a binary operator (other than
<</>>) whose sibling operand has a concrete numeric type from a non-(unsuffixed-literal) source as supplying an explicit type bound, the same way it already does for fn arguments and struct fields. The check propagates outer bounds downward, so transitively constrained literals such as the inner ones ina + 1 + 2and(1 + 2) + aare also accepted.Shifts are intentionally skipped because
<<and>>permit each side to have its own integer type, so a typed RHS does not constrain a literal LHS:Cases where neither side carries explicit type information continue to warn (e.g.
let _ = 1 + 2;).changelog: [
default_numeric_fallback]: do not warn on numeric literals whose type is constrained by a typed operand in a binary expression