Auto merge of #6046 - rail-rain:change_criteria_non_copy_const, r=flip1995
Change the criteria of `interior_mutable_const`
This implements my suggestion [here](https://github.com/rust-lang/rust-clippy/issues/5050#issuecomment-680310889), and so hopefully fixes #5050.
* stop linting associated types and generic type parameters
* start linting ones in trait impls
whose corresponding definitions in the traits are generic
* remove the `is_copy` check
as presumably the only purpose of it is to allow
generics with `Copy` bounds as `Freeze` is internal
and generics are no longer linted
* remove the term 'copy' from the tests
as being `Copy` no longer have meaning
---
changelog: Change the criteria of `declare_interior_mutable_const` and `borrow_interior_mutable_const` to narrow the lints to only lint things that defenitly is a interior mutable type, not potentially.
rail [Tue, 25 Aug 2020 03:13:40 +0000 (15:13 +1200)]
Change the criteria of `interior_mutable_const`
* stop linting associated types and generic type parameters
* start linting ones in trait impls
whose corresponding definitions in the traits are generic
* remove the `is_copy` check
as presumably the only purpose of it is to allow
generics with `Copy` bounds as `Freeze` is internal
and generics are no longer linted
* remove the term 'copy' from the tests
as being `Copy` no longer have meaning
Auto merge of #6025 - thomcc:compare_exchange_atomics, r=flip1995
Extend invalid_atomic_ordering for compare_exchange{,_weak} and fetch_update
changelog: The invalid_atomic_ordering lint can now detect misuse of `compare_exchange`, `compare_exchange_weak`, and `fetch_update`.
---
I was surprised not to find an issue or existing support here, since these are the functions which are always hardest to get the ordering right on for me (as the allowed orderings for `fail` depend on the `success` parameter).
I believe this lint now covers all atomic methods which care about their ordering now, but I could be wrong.
Hopefully I didn't forget to do anything for the PR!
Auto merge of #6057 - giraffate:update_doc_about_moving_to_zulip, r=flip1995
Update documentation about moving from Discord to Zulip
Moving from Discord to Zulip was discussed at https://github.com/rust-lang/rust-clippy/issues/5943 and new stream in Zulip was created at https://github.com/rust-lang/rust-clippy/issues/5943#issuecomment-691984366.
In a large code base a lot of times errors are ignored by using something like:
```rust
foo.map_err(|_| Some::Enum)?;
```
This drops the original error in favor of a enum that will not have the original error's context. This lint helps catch throwing away the original error in favor of an enum without its context.
---
*Please keep the line below*
changelog: Added map_err_ignore lint
Michael Wright [Mon, 14 Sep 2020 04:11:35 +0000 (06:11 +0200)]
New lint: `manual-strip`
Add a new lint, `manual-strip`, that suggests using the `str::strip_prefix`
and `str::strip_suffix` methods introduced in Rust 1.45 when the same
functionality is performed 'manually'.
Auto merge of #75800 - Aaron1011:feature/full-nt-tokens, r=petrochenkov
Attach tokens to all AST types used in `Nonterminal`
We perform token capturing when we have outer attributes (for nonterminals that support attributes - e.g. `Stmt`), or when we parse a `Nonterminal` for a `macro_rules!` argument. The full list of `Nonterminals` affected by this PR is:
Of these nonterminals, only `NtStmt` and `NtLiteral` (which is actually just an `Expr`), support outer attributes - the rest only ever have token capturing perform when they match a `macro_rules!` argument.
This makes progress towards solving https://github.com/rust-lang/rust/issues/43081 - we now collect tokens for everything that might need them. However, we still need to handle `#[cfg]`, inner attributes, and misc pretty-printing issues (e.g. #75734)
I've separated the changes into (mostly) independent commits, which could be split into individual PRs for each `Nonterminal` variant. The purpose of having them all in one PR is to do a single Crater run for all of them.
Most of the changes in this PR are trivial (adding `tokens: None` everywhere we construct the various AST structs). The significant changes are:
* `ast::Visibility` is changed from `type Visibility = Spanned<VisibilityKind>` to a `struct Visibility { kind, span, tokens }`.
* `maybe_collect_tokens` is made generic, and used for both `ast::Expr` and `ast::Stmt`.
* Some of the statement-parsing functions are refactored so that we can capture the trailing semicolon.
* `Nonterminal` and `Expr` both grew by 8 bytes, as some of the structs which are stored inline (rather than behind a `P`) now have an `Option<TokenStream>` field. Hopefully the performance impact of doing this is negligible.
Auto merge of #5977 - xvschneider:AddLintPanicInResult, r=matthiaskrgr
Add lint panic in result
### Change
Adding a new "restriction" lint that will emit a warning when using "panic", "unimplemented" or "unreachable" in a function of type option/result.
### Motivation
Some codebases must avoid crashes at all costs, and hence functions of type option/result must return an error instead of crashing.
### Test plan
Running:
TESTNAME=panic_in_result cargo uitest ---
Auto merge of #6019 - rail-rain:improve_known_probs_mut_key, r=flip1995
Improve the "known problems" section of `interior_mutable_key`
* Remove the mention to `Rc` and `Arc` as these are `Freeze` (despite my intuition) so the lint correctly handles already.
* Instead, explain what could cause a false positive, and mention `bytes` as an example.
---
changelog: Improved the "known problems" section of `interior_mutable_key`
Auto merge of #5931 - montrivo:unit-arg, r=flip1995
improve the suggestion of the lint `unit-arg`
Fixes #5823
Fixes #6015
Changes
```
help: move the expression in front of the call...
|
3 | g();
|
help: ...and use a unit literal instead
|
3 | o.map_or((), |i| f(i))
|
```
into
```
help: move the expression in front of the call and replace it with the unit literal `()`
|
3 | g();
| o.map_or((), |i| f(i))
|
```
changelog: improve the suggestion of the lint `unit-arg`
Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obk
Add CONST_ITEM_MUTATION lint
Fixes #74053
Fixes #55721
This PR adds a new lint `CONST_ITEM_MUTATION`.
Given an item `const FOO: SomeType = ..`, this lint fires on:
* Attempting to write directly to a field (`FOO.field = some_val`) or
array entry (`FOO.array_field[0] = val`)
* Taking a mutable reference to the `const` item (`&mut FOO`), including
through an autoderef `FOO.some_mut_self_method()`
The lint message explains that since each use of a constant creates a
new temporary, the original `const` item will not be modified.
Aaron Hill [Tue, 8 Sep 2020 21:59:43 +0000 (17:59 -0400)]
Adjust Clippy for CONST_ITEM_MUTATION lint
We no longer lint assignments to const item fields in the
`temporary_assignment` lint, since this is now covered by the
`CONST_ITEM_MUTATION` lint.
Additionally, we `#![allow(const_item_mutation)]` in the
`borrow_interior_mutable_const.rs` test. Clippy UI tests are run with
`-D warnings`, which seems to cause builtin lints to prevent Clippy
lints from running.
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.