Lint pass to warn about integer suffixes #3307
Comments
|
The programmer may want a shorthand way to say "I really want this to be unsigned" though. I guess they could say |
|
That's why it'll just be a lint pass and not an error :-) |
|
Okay, then I'd vote for off by default :) |
|
Nominating for production-ready. |
|
Yeah, I don't know; this doesn't even really seem like a code smell to me, just a normal style choice, like variable naming or annotating-or-not each local variable type. They're totally necessary in some cases, and are shorter than type annotations. Maybe it's just a question of the limit of what we consider "lint", but ISTM this path leads to a lint mode for every possible AST construct, and each lint pass does take a (small) amount of time to walk the AST of every function. They're not fused. In any case, I don't feel this should block "production ready" |
|
This is also very easy to grep for, if necessary. |
|
just a bug, removing milestone/nomination. |
|
Closing; this seems sufficiently innocuous that it doesn't really scream for a lint pass. Reopen if you feel otherwise. |
This moves the range_minus_one lint to the pedantic category, so there will not be any warnings emitted by default. This should work around problems where the suggestion is impossible to resolve due to the range consumer only accepting a specific range implementation, rather than the `RangeBounds` trait (see rust-lang#3307). While it is possible to work around this by extracting the boundary into a variable, I don't think clippy should encourage people to disable or work around lints, but instead the lints should be fixable. So hopefully this will help until a proper implementation checks what the range is used for.
Move range_minus_one to pedantic This moves the range_minus_one lint to the pedantic category, so there will not be any warnings emitted by default. This should work around problems where the suggestion is impossible to resolve due to the range consumer only accepting a specific range implementation, rather than the `RangeBounds` trait (see rust-lang#3307). While it is possible to work around this by extracting the boundary into a variable, I don't think clippy should encourage people to disable or work around lints, but instead the lints should be fixable. So hopefully this will help until a proper implementation checks what the range is used for. *Please keep the line below* changelog: move [`range_minus_one`] to pedantic
tests/pass/concurrency/sync: try to make it less likely for the test to fail on macOS We're already sleeping a full second though. How can our test be stalled for an entire second, what are these CI runners doing?!?
The rust type inference for closures doesn't work in the particular use case we are using it for ensures clauses. By creating a helper function, we change the path the rust type inference takes and lets the type of the closure be identified properly. This means type annotations are no longer required within ensures clauses. Resolves rust-lang#3304 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
A lint pass to warn about
42uand such would be great, since the suffixes are no longer necessary.The text was updated successfully, but these errors were encountered: