Add `separated_literal_suffix` as an alternative for
`unseparated_literal_suffix`
This commit adds a configuration `literal-suffix-style` to enforce a
specific style for unseparated_literal_suffix. The configuration accepts
two values:
- "separated"
enforce all literals to be written separately (e.g. `123_i32`)
- "unseparated"
enforce all literals to be written as unseparated (e.g. `123i32`)
Not specifying a value means that there is no preference on style and
any style should not be warned.
Because https://github.com/rust-lang/rust/blob/6cdd42f9f8dd4e5e5ba0aa816bc4c99ab8b102f9/library/std/src/primitive_docs.rs#L538
/// Arrays of sizes from 0 to 32 (inclusive) implement [`Default`] trait
/// if the element type allows it. As a stopgap, trait implementations are
/// statically generated up to size 32.
So here to detect this situation.
changelog: [`derivable_impls`]: No longer lints when arrays bigger than 32 elements are involved
This needs a review this time. Especially https://github.com/rust-lang/rust-clippy/commit/521bf8f0fa18c7f130505f0a902ab0e65a76cec2 cc `@camsteffen` I think this is necessary now, because `itertools` is no longer a dependency of `clippy_utils` and therefore this path can't be found :thinking:
( I forgot about the sync last week. I should get to document this process better, so other people can do it when I'm not around )
Auto merge of #7608 - andrewpollack:7594/while_let_some_result, r=Manishearth
#7594: Adding new 'while_let_some_result' linting
Excited for the opportunity to contribute to Clippy! Since the latest Bay Area Rust Meetup, I've been looking for an opportunity and found it :smile:
Please let me know how I can improve this PR! Much of it is similar to ``[`if_let_some_result`]``, but I followed the description in the issue to create its own linting rules. Looking forward to feedback, and continuing to work on Clippy in the future!
changelog: Renamed Lint: `if_let_some_result` is now called [`match_result_ok`]. Now also handles `while let` case.
Auto merge of #7692 - workingjubilee:float-cmp-not-wrong, r=giraffate
Demote float_cmp to pedantic
See this issue: https://github.com/rust-lang/rust-clippy/issues/7666
This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them.
A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons.
changelog: Demote [`float_cmp`] from correctness to pedantic lints
Auto merge of #7722 - dtolnay-contrib:float, r=giraffate
Stop suggesting a float truncation that is not shorter
Fixes #7721.
Previously Clippy would say that a number has excessive precision even if it has the minimum possible precision for the floating point value that it corresponds to.
changelog: Fix [`excessive_precision`] being triggered on floats that are already written in shortest form
Auto merge of #89030 - nbdd0121:box2, r=jonas-schievink
Introduce `Rvalue::ShallowInitBox`
Polished version of #88700.
Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward.
In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP.
`NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient.
Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
Rollup merge of #89001 - jackh726:binder-cleanup, r=nikomatsakis
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
Auto merge of #7704 - camsteffen:pedantic-occasional, r=Manishearth
Tweak pedantic description for occasional FPs
changelog: none
Okay this is getting a bit picky (you might even say pedantic). I think we need to be careful not use the pedantic category as cover-all for lints with any amount of false positives. Lints with a high degree of FPs should be nursery or restriction IMO. If the pedantic category were to yield, say hypothetically, over 50% FPs, it would just be too annoying to use at all (to be sure, "too picky for me" is not a FP).
Auto merge of #89158 - the8472:rollup-3e4ijth, r=the8472
Rollup of 12 pull requests
Successful merges:
- #88795 (Print a note if a character literal contains a variation selector)
- #89015 (core::ascii::escape_default: reduce struct size)
- #89078 (Cleanup: Remove needless reference in ParentHirIterator)
- #89086 (Stabilize `Iterator::map_while`)
- #89096 ([bootstrap] Improve the error message when `ninja` is not found to link to installation instructions)
- #89113 (dont `.ensure()` the `thir_abstract_const` query call in `mir_build`)
- #89114 (Fixes a technicality regarding the size of C's `char` type)
- #89115 (:arrow_up: rust-analyzer)
- #89126 (Fix ICE when `indirect_structural_match` is allowed)
- #89141 (Impl `Error` for `FromSecsError` without foreign type)
- #89142 (Fix match for placeholder region)
- #89147 (add case for checking const refs in check_const_value_eq)
Auto merge of #89103 - Mark-Simulacrum:migrate-2021, r=estebank
Migrate in-tree crates to 2021
This replaces #89075 (cherry picking some of the commits from there), and closes #88637 and fixes #89074.
It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there.
I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first.
Originally, the intent was to support cargo fix --edition within bootstrap, but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation, and only resetting sysroots on check. Further, it was found that cargo fix doesn't behave too well with "not quite workspaces", such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools, and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately.
It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c877110748296760aefddc21a0ea1d316 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.
Auto merge of #7694 - Jarcho:lintcheck_retry, r=matthiaskrgr
Retry on some download errors in lintcheck
I'm currently on spotty wifi right now. It is shocking the number of things that break when you lose connection for a few seconds. Some 500 errors should probably also be retried, but this fixes my issue.
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
Mark Rousskov [Sat, 18 Sep 2021 21:37:24 +0000 (17:37 -0400)]
Enable 2021 compatibility lints for all in-tree code
This just applies the suggested fixes from the compatibility warnings,
leaving any that are in practice spurious in. This is primarily intended to
provide a starting point to identify possible fixes to the migrations (e.g., by
avoiding spurious warnings).
A secondary commit cleans these up where they are false positives (as is true in
many of the cases).
projects / rust.git / log