Auto merge of #6016 - giraffate:restrict_same_item_push, r=ebroto
Restrict `same_item_push` to suppress false positives
It only emits a lint when the pushed item is a literal, a constant and an immutable binding that are initialized with those, as discussed in https://github.com/rust-lang/rust-clippy/pull/5997#pullrequestreview-483005186.
Auto merge of #76044 - ecstatic-morse:dataflow-lattice, r=oli-obk
Support dataflow problems on arbitrary lattices
This PR implements last of the proposed extensions I mentioned in the design meeting for the original dataflow refactor. It extends the current dataflow framework to work with arbitrary lattices, not just `BitSet`s. This is a prerequisite for dataflow-enabled MIR const-propagation. Personally, I am skeptical of the usefulness of doing const-propagation pre-monomorphization, since many useful constants only become known after monomorphization (e.g. `size_of::<T>()`) and users have a natural tendency to hand-optimize the rest. It's probably worth exprimenting with, however, and others have shown interest cc `@rust-lang/wg-mir-opt.`
The `Idx` associated type is moved from `AnalysisDomain` to `GenKillAnalysis` and replaced with an associated `Domain` type that must implement `JoinSemiLattice`. Like before, each `Analysis` defines the "bottom value" for its domain, but can no longer override the dataflow join operator. Analyses that want to use set intersection must now use the `lattice::Dual` newtype. `GenKillAnalysis` impls have an additional requirement that `Self::Domain: BorrowMut<BitSet<Self::Idx>>`, which effectively means that they must use `BitSet<Self::Idx>` or `lattice::Dual<BitSet<Self::Idx>>` as their domain.
Most of these changes were mechanical. However, because a `Domain` is no longer always a powerset of some index type, we can no longer use an `IndexVec<BasicBlock, GenKillSet<A::Idx>>>` to store cached block transfer functions. Instead, we use a boxed `dyn Fn` trait object. I discuss a few alternatives to the current approach in a commit message.
The majority of new lines of code are to preserve existing Graphviz diagrams for those unlucky enough to have to debug dataflow analyses. I find these diagrams incredibly useful when things are going wrong and considered regressing them unacceptable, especially the pretty-printing of `MovePathIndex`s, which are used in many dataflow analyses. This required a parallel `fmt` trait used only for printing dataflow domains, as well as a refactoring of the `graphviz` module now that we cannot expect the domain to be a `BitSet`. Some features did have to be removed, such as the gen/kill display mode (which I didn't use but existed to mirror the output of the old dataflow framework) and line wrapping. Since I had to rewrite much of it anyway, I took the opportunity to switch to a `Visitor` for printing dataflow state diffs instead of using cursors, which are error prone for code that must be generic over both forward and backward analyses. As a side-effect of this change, we no longer have quadratic behavior when writing graphviz diagrams for backward dataflow analyses.
Auto merge of #6006 - ebroto:6001_unnecessary_sort_by, r=Manishearth
Restrict unnecessary_sort_by to non-reference, Copy types
`Vec::sort_by_key` closure parameter is `F: FnMut(&T) -> K`. The lint's suggestion destructures the `T` parameter; this was probably done to avoid different unnamed lifetimes when `K = Reverse<&T>`.
This change fixes two issues:
* Destructuring T when T is non-reference requires the type to be Copy, otherwise we would try to move from a shared reference. We make sure `T: Copy` holds.
* Make sure `T` is actually non-reference. I didn't go for destructuring multiple levels of references, as we would have to compensate in the closure body by removing derefs and maybe adding parens, which would add more complexity.
changelog: Restrict [`unnecessary_sort_by`] to non-reference, Copy types
Auto merge of #6009 - Ryan1729:show-line_count-and-max_lines-in-too_many_lines-lint-message, r=phansch
Show line count and max lines in too_many_lines lint message
This PR adds the current amount of lines and the current maximum number of lines in the message for the `too_many_lines` lint, in a similar way as the `too_many_arguments` lint currently does.
changelog: show the line count and the maximum lines in the message for the `too_many_lines` lint.
Auto merge of #76160 - scileo:format-recovery, r=petrochenkov
Improve recovery on malformed format call
The token following a format expression should be a comma. However, when it is replaced with a similar token (such as a dot), then the corresponding error is emitted, but the token is treated as a comma, and the parsing step continues.
Auto merge of #5999 - rail-rain:fix_fp_transmute_ptr_to_ptr_in_consts, r=ebroto
Fix a fp in `transmute_ptr_to_ptr`
fixes #5959
changelog: Fix a false positive in `transmute_ptr_to_ptr` that the lint fires when `transmute` is used to cast a reference in const contexts although dereferencing raw pointers in consts is unstable.
Auto merge of #5993 - taiki-e:default_trait_access, r=phansch
default_trait_access: Fix wrong suggestion
https://github.com/rust-lang/rust-clippy/issues/5975#issuecomment-683751131
> I think the underlying problem is clippy suggests code with complete parameters, not clippy triggers this lint even for complex types. AFAIK, If code compiles with `Default::default`, it doesn't need to specify any parameters, as type inference is working. (So, in this case, `default_trait_access` should suggest `RefCell::default`.)
bors [Wed, 26 Aug 2020 23:38:34 +0000 (23:38 +0000)]
Auto merge of #5957 - xvschneider:AddUnwrapInsideResultLint, r=yaahc
Adding new lint to prevent usage of 'unwrap' inside functions that re…
### Change
Adding a new lint that will emit a warning when using "unwrap" or "expect" inside a function that returns result.
### Motivation
These functions promote recoverable errors to non-recoverable errors which may be undesirable in code bases which wish to avoid panics.
### Test plan
Running:
`TESTNAME=unwrap_in_result cargo uitest
`---
bors [Wed, 26 Aug 2020 22:52:47 +0000 (22:52 +0000)]
Auto merge of #5968 - rail-rain:fix_use_snippet_with_applicability, r=flip1995
Fix the wrong use of `snippet_with_applicability`
For the context, please see https://github.com/rust-lang/rust-clippy/issues/5822#issuecomment-680749728 and https://github.com/rust-lang/rust-clippy/issues/5822#issuecomment-680783381.
bors [Wed, 26 Aug 2020 18:15:42 +0000 (18:15 +0000)]
Auto merge of #5966 - 1c3t3a:1c3t3a-dev-5819-fix, r=Manishearth
Corrects the float_equality_without_abs lint
Fixes an issue in the `float_equality_without_abs` lint. The lint suggestion was configured in a way that it lints the whole error and not just the subtraction part. In the current configuration the lint would suggest to change the expression in a wrong way, e.g.
```rust
let _ = (a - b) < f32::EPSILON; // before
let _ = (a - b).abs(); // after
```
This was dicovered by @flip1995. (See discussion of PR #5952).
Also the suggestion is now formatted via `utils::sugg`.
changelog: none
Michael Wright [Tue, 25 Aug 2020 03:53:28 +0000 (05:53 +0200)]
Fix intermittent build error
The fmt test will cause clippy dev to be compiled and run. The clippy dev
dependencies are currently stored at `target/debug/deps` when this happens.
This location sometimes causes conflicts with ui tests which result in the
build error "thread 'compile_test' panicked at 'Found multiple rlibs for crate
`regex` ...".
This commit forces the clippy_dev dependencies to be stored under
`clippy_dev/target/` which seems to resolve this problem.