Fix matadata collection configuration formatting

Add higher docs and remove some unneeded fields

Fix remaining dogfood errors

Except for the missing docs ones

Fix dogfood

Fix manual_match with let-expressions

Merge remote-tracking branch 'upstream/master' into rustup2

Auto merge of #7619 - UnrealApex:patch-1, r=flip1995

Update README.md

Capitalized proper noun.
changelog:none

Auto merge of #7617 - xFrednet:0000-link-diag-item-docs, r=giraffate

Reference new diagnostic item docs in our docs :)

The title says it all. The rustc dev guide now has some information about diagnostic items that are worthwhile linking to :upside_down_face:

---

changelog: none

Update README.md

Reference new diagnostic item docs in our docs :)

Auto merge of #7605 - xordi:issue-7548-fix, r=giraffate

Issue 7548 fix

Close #7548

changelog: [`bool_assert_comparison`] fixes should be emitted only in case they are comparing a value of a type that implements the `Not` trait with an output of type `bool` against a boolean literal.

Fix function and variable names

Fix CI errors

Add new ui tests

Check for Not trait implementation

Fix clippy for let-else

Auto merge of #7573 - Jarcho:option_if_let_else, r=giraffate

Fix `option_if_let_else`

fixes: #5822
fixes: #6737
fixes: #7567

The inference from #6137 still exists so I'm not sure if this should be moved from the nursery. Before doing that though I'd almost want to see this split into two lints. One suggesting `map_or` and the other suggesting `map_or_else`.

`map_or_else` tends to have longer expressions for both branches so it doesn't end up much shorter than a match expression in practice. It also seems most people find it harder to read. `map_or` at least has the terseness benefit of being on one line most of the time, especially when the `None` branch is just a literal or path expression.

changelog: `break` and `continue` statments local to the would-be closure are allowed in `option_if_let_else`
changelog: don't lint in const contexts  in `option_if_let_else`
changelog: don't lint when yield expressions are used  in `option_if_let_else`
changelog: don't lint when the captures made by the would-be closure conflict with the other branch  in `option_if_let_else`
changelog: don't lint when a field of a local is used when the type could be pontentially moved from  in `option_if_let_else`
changelog: in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure  in `option_if_let_else`

`feature(const_generics)` -> `feature(const_param_types)`

rename const_evaluatable_checked to generic_const_exprs

:sparkles:

Teach tools that macros are now HIR items

Treat macros as HIR items

Auto merge of #7600 - xFrednet:0000-update-issue-templates, r=camsteffen

Updated issue templates(formatting and rustbot label reference)

This PR updates our issue templates. The changes are:

1. **Make the *Meta* section smaller and not indented**

    The current format sometimes gets messed up when a user simply pasts the rustc version into the issue without indenting it to match the code block. Removing the indention should hopefully help with formatting in the future.

    <details><summary>Example of messed up formatting </summary>

    

    </details>

    Additionally, I've removed the Version of Clippy from the template. Every issue that I have seen had matching rustc and Clippy versions, and just asking for `rustc -Vv` makes the issue look cleaner IMO.

2. **Add a comment explaining how additional labels can be added with ``@rustbot` label +<label>`. The explanation looks like this:**

    ```
    <!--
    Additional labels can be added to this issue by including the following command:

    `@rustbot` label +<label>

    Common labels for this issue type are:
    * `I-suggestion-causes-error`
    -->
    ```

    The example ``@rustbot`` call can sadly not be marked as code inside a comment block. But the example will not cause the bot to add any labels. See rust-lang/rust-clippy#7599

---

changelog: none

cc: `@rust-lang/clippy`

Small cleanup of `option_if_let_else` and additional tests.

Auto merge of #7602 - flip1995:needless_collect_appl, r=xFrednet

Set applicability of needless_collect to MaybeIncorrect

Fixes rust-lang/rust#88333

changelog: Set applicability of [`needless_collect`] to MaybeIncorrect

Auto merge of #7583 - dswij:match-trait-docs, r=xFrednet

Tweak common tool docs on type-implement-trait check

See https://github.com/rust-lang/rust-clippy/pull/7562#issuecomment-898240963.

changelog: none

Update doc/common_tools_writing_lints.md

Add missing import `paths` for the doc example.

Co-authored-by: Fridtjof Stoldt <xFrednet@gmail.com>

Update common tool docs on type implement trait check

Common tool documentation uses `match_trait_method` which is deprecated.
Additionally, adds information on why `is_trait_method` is not the
preferred way.

Set applicability of needless_collect to MaybeIncorrect

update `TypeFlags` to deal with missing ct substs

add `tcx` to `fn walk`

make unevaluated const substs optional

require a `tcx` for `TypeVisitor`

Auto merge of #7543 - DevinR528:disallowed-mod, r=Manishearth

Add module_style lint to style

changelog: Add new [`module_style`] style lint

This is a configurable (no mod file/mod file) lint that determines if `mod.rs` is used consistently or if `mod.rs` is never used (using the new mod layout).

Updated issue templates(formatting and rustbot label reference)

Auto merge of #7453 - F3real:assume_function_calls_have_side_effect, r=flip1995

Don't report function calls as unnecessary operation if used in array index

Attempts to fix: #7412

changelog: Don't report function calls used in indexing as unnecessary operation. [`unnecessary_operation`]

Add module_style lint to restriction

Add tests for disallowed_mod in ui-cargo test section

Use correct algorithm to determine if mod.rs is missing

Move to two lints and remove config option

Switch lint names so they read "warn on ..."

Emit the same help info for self_named_mod_file warnings

Bail when both lints are Allow

Reword help message for both module_style lints

Auto merge of #7592 - lengyijun:redundant_allocation, r=camsteffen

redundant_allocation: fix 7487

Fixes #7487

changelog: [`redundant_allocation`] - allow `Box<Box<dyn T>>` which replaces wide pointers with thin pointers

redundant_allocation: fix 7487

Auto merge of #83302 - camsteffen:write-piece-unchecked, r=dtolnay

Get piece unchecked in `write`

We already use specialized `zip`, but it seems like we can do a little better by not checking `pieces` length at all.

`Arguments` constructors are now unsafe. So the `format_args!` expansion now includes an `unsafe` block.

<details>
<summary>Local Bench Diff</summary>

```text
 name                        before ns/iter  after ns/iter  diff ns/iter   diff %  speedup
 fmt::write_str_macro1       22,967          19,718               -3,249  -14.15%   x 1.16
 fmt::write_str_macro2       35,527          32,654               -2,873   -8.09%   x 1.09
 fmt::write_str_macro_debug  571,953         575,973               4,020    0.70%   x 0.99
 fmt::write_str_ref          9,579           9,459                  -120   -1.25%   x 1.01
 fmt::write_str_value        9,573           9,572                    -1   -0.01%   x 1.00
 fmt::write_u128_max         176             173                      -3   -1.70%   x 1.02
 fmt::write_u128_min         138             134                      -4   -2.90%   x 1.03
 fmt::write_u64_max          139             136                      -3   -2.16%   x 1.02
 fmt::write_u64_min          129             135                       6    4.65%   x 0.96
 fmt::write_vec_macro1       24,401          22,273               -2,128   -8.72%   x 1.10
 fmt::write_vec_macro2       37,096          35,602               -1,494   -4.03%   x 1.04
 fmt::write_vec_macro_debug  588,291         589,575               1,284    0.22%   x 1.00
 fmt::write_vec_ref          9,568           9,732                   164    1.71%   x 0.98
 fmt::write_vec_value        9,516           9,625                   109    1.15%   x 0.99
```
</details>

Auto merge of #7595 - camsteffen:branches-sharing-nursery, r=Manishearth

Move branches_sharing_code to nursery

changelog: Move [`branches_sharing_code`] to nursery

...since there are quite a few [open bugs](https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue+is%3Aopen+branches_sharing_code).

Rollup merge of #88230 - steffahn:a_an, r=oli-obk

Fix typos “a”→“an”

Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.

While automation was used to find these, every change was checked manually.

Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
  _folks @ rust-analyzer are fast at merging…_
  * https://github.com/rust-analyzer/rust-analyzer/pull/9985
  * https://github.com/rust-analyzer/rust-analyzer/pull/9987
  * https://github.com/rust-analyzer/rust-analyzer/pull/9989

_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._

<hr>

This has some overlap with #88226, but neither is a strict superset of the other.

If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.

Move branches_sharing_code to nursery

Auto merge of #7593 - camsteffen:remove-stderr-limit, r=Manishearth

Remove stderr limit

changelog: none

Discussed at https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Increase.20test.20stderr.20length.20limit.3F

Remove stderr limit

Auto merge of #7539 - Labelray:master, r=camsteffen

Add new lint `negative_feature_names` and `redundant_feature_names`

Add new lint [`negative_feature_names`] to detect feature names with prefixes `no-` or `not-` and new lint [`redundant_feature_names`] to detect feature names with prefixes `use-`, `with-` or suffix `-support`
changelog: Add new lint [`negative_feature_names`] and [`redundant_feature_names`]

Add new lints `negative_feature_names` and `redundant_feature_names`

Rollup merge of #88211 - petrochenkov:withhilo, r=jyn514

cleanup: `Span::new` -> `Span::with_lo`

Extracted from https://github.com/rust-lang/rust/pull/84373 as suggested in https://github.com/rust-lang/rust/pull/84373#issuecomment-857773867.
It turned out less useful then I expected, but anyway.
r? `@cjgillot`
`@bors` rollup

Fix typos “an”→“a” and a few different ones that appeared in the same search

Fix more “a”/“an” typos

Fix typos “a”→“an”

Auto merge of #88163 - camsteffen:collapsible-match-fix, r=Manishearth

Fix clippy::collapsible_match with let expressions

This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap.

The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR).

Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591
cc `@rust-lang/clippy`
`@xFrednet` do you want to review this?

cleanup: `Span::new` -> `Span::with_lo`

introduce a Coerce predicate

Fix clippy let expressions fallout

remove box_syntax uses from cranelift and tools

Auto merge of #7565 - Jarcho:manual_split_once, r=llogiq

New lint `manual_split_once`

This is a WIP because it still needs to recognize more patterns. Currently handles:

```rust
s.splitn(2, ' ').next();
s.splitn(2, ' ').nth(0)
s.splitn(2, ' ').nth(1);
s.splitn(2, ' ').skip(0).next();
s.splitn(2, ' ').skip(1).next();
s.splitn(2, ' ').next_tuple(); // from itertools

// as well as `unwrap()` and `?` forms
```

Still to do:

```rust
let mut iter = s.splitn(2, ' ');
(iter.next().unwrap(), iter.next()?)

let mut iter = s.splitn(2, ' ');
let key = iter.next().unwrap();
let value = iter.next()?;
```

Suggestions on other patterns to check for would be useful. I've done a search on github for uses of `splitn`. Still have yet to actually look through the results.

There's also the question of whether the lint shouold trigger on all uses of `splitn` with two values, or only on recognized usages. The former could have false positives where it couldn't be replaced, but I'm not sure how common that would be.

changelog: Add lint `manual_split_once`

Auto merge of #7578 - xFrednet:7172-update-some-docs, r=camsteffen

Small documentation update for the new metadata_collector

Just small documentation updates after the merge of the new metadata collection. I'm also here to deliver on the promised fairy tale:

*Once upon a time, there was a world with many languages. One of the oldest was C a very versatile language that gave great power for the cost of great complexity and manual work. C was so powerful that it was able to create new languages. There is Java a versatile language often used by companies and in formal settings. Python that focused on readability and rapid prototyping capabilities. JavaScript which has some interesting edge cases but was still loved and widely used in the world. Together they build the foundation of our world and continue to shape the interactions between kingdoms worldwide.*

*C ruled as the king of Linux and other operating systems alongside the Queen C++. Together they were powerful leaders, in fact so powerful that they have been ruling this world for over 49 years. They remain happy together and loved by the community. However, with great power comes great responsibility! The two of them have a dark secret. To tell the truth, they sometimes suffer from memory loss and even worse in some instances from race conditions.*

*A mystical creature called Firefox lead to the creation of Mozilla, a global organization fighting for privacy and for their market share in the browser marked. As part of this fight, they started to modify parts of Firefox and eventually created Servo. A completely new creature with a new language called Rust. This new form of communication was focussed on correctness, speed and a new model of memory management.*

*Rust grew up over several years with modification to syntax, content among other things. Finally, in 2015 Rust has reached adulthood which enabled it to take part in the global discourse and shape the future of our world. Some even say that this was the start of a new area withing language design.*

*Rust had already started to build its kingdom and was now the head of a complete organization, with teams being in charge of individual tools used for further development. One team focussing on further improving Rust when it comes to complexity, style and performance was **The Clippy Team**. Its members were a friendly bunch, with mages and wizards among them.*

*With the goal of giving more power to Rust, they identified a Python tool inside Clippy that could be rewritten. This led to the creating of the **Metadata collection monster**. This monster soon replaced the old Python tool and allowed for new creative additions inside Clippy's lint list. With the eradication of the old tool, there came a possibility to update the configuration documentation to span over a lager area. This was done, but some doc comments remained until now in memory of the old tool. This is now the PR that removes these doc comments.*

---

I have to stop now, this already took way longer than the actual changes. It probably also contains some spelling mistakes, but oh well. I hope you get the gist of it :upside_down_face:.

---

r? `@camsteffen`

changelog: none

Small documentation update for the new metadata_collector

Auto merge of #7574 - Jarcho:expl_impl_clone_on_copy_doc, r=giraffate

Update docs for `expl_impl_clone_on_copy`

The known issue was fixed in #6993. I missed updating the docs then, so it's happening now.

changelog: None

Update docs for `expl_impl_clone_on_copy`. Bug was fixed in 879fa5c9721c89c27be6a9db5f51d935a51f549b1~

Fix `option_if_let_else`
* `break` and `continue` statments local to the would-be closure are allowed
* don't lint in const contexts
* don't lint when yield expressions are used
* don't lint when the captures made by the would-be closure conflict with the other branch
* don't lint when a field of a local is used when the type could be pontentially moved from
* in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure

clippy: Fix format_args expansion parsing

Update docs for `manual_split_once`

Add lint `manual_split_once`

Add `for_each_local_usage`. Switch `LocalUsedVisitor` to a function.

Auto merge of #7566 - dswij:manual-flatten-use, r=xFrednet

Check expr usage for  `manual_flatten`

Fixes #6784
Fixes #7538

`manual_flatten` should not trigger when `if let` match expression will be used.

changelog: [`manual_flatten`] checks for expr usage after `if let`

Check `if let` expr usage in `manual_flatten`

`manual_flatten` should not trigger when match expression in `if let` is
going to be used.

Add false positive test for `manual_flatten`

Add a scenario where `manual_flatten` is triggered when match expression will still be used after the match in `if let`.

Auto merge of #84039 - jyn514:uplift-atomic-ordering, r=wesleywiser

Uplift the invalid_atomic_ordering lint from clippy to rustc

This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.

r? `@lcnr` since you reviewed the last one, but feel free to reassign.

---

This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.

As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.

As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.

In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?

---

Some notes on the code for reviewers / others below

## Changes from clippy

The code is changed from [the implementation in clippy](https://github.com/rust-lang/rust-clippy/blob/68cf94f6a66e47234e3adefc6dfbe806cd6ad164/clippy_lints/src/atomic_ordering.rs) in the following ways:

1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
    - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
    - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
    - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
    - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
    - grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
    - function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
    - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).

## Potential issues

(This is just about the code in this PR, not conceptual issues with the lint or anything)

1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
    - It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.

2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
    - I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.

3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.

4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).

Uplift the `invalid_atomic_ordering` lint from clippy to rustc

- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead

  I ran into tons of trouble with this because apparently the change to
  store HIR attrs in a side table also gave the DefIds of the
  constructor instead of the variant itself. So I had to change
  `matches_ordering` to also check the grandparent of the defid as well.

- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
  Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches

  This prevents an ICE when there aren't enough arguments.

- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`

  The functions take values, so this couldn't ever be anything else.

- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow

Auto merge of #7531 - Jarcho:manual_map_7413, r=camsteffen

Manual map 7413

fixes: #7413

This only fixes the specific problem from #7413, not the general case. The full fix requires interacting with the borrow checker to determine the lifetime of all the borrows made in the function. I'll open an issue about it later.

changelog: Don't suggest using `map` when the option is borrowed in the match, and also consumed in the arm.
changelog: Locals declared within the would-be closure will not prevent the closure from being suggested in `manual_map` and `map_entry`

Use `each_binding_or_first` in `capture_local_usage`

Auto merge of #7521 - rukai:fix_lintcheck_local_path_handling, r=camsteffen

lintcheck always copies in a fresh crate when provided with a crate path

changelog: none

When lintcheck is run on local crates it copies the crate to `target/lintcheck/sources/crate_name` on the first run only.
Then in subsequent runs of lintcheck it reuses this same copy.
This caching behaviour makes sense when dealing with immutable crates.io releases and git commits.
However it is quite surprising that the changes to my local crate are not used when I run lintcheck.

To fix this I removed the copy, instead clippy runs directly off the provided crate folder.
I have tested this and have not observed any negative effects from doing this.
But maybe i'm missing something as im not familiar with clippy!

Alternatively we could make it copy the entire crate every run, but that seems problematic to me as multi-gigabyte target folders will take a long time to copy and wear down SSDs for developers who frequently run lintcheck.

Lintcheck always copies in a fresh crate when provided with a crate path
but skips directories containing CACHEDIR.TAG e.g. the target/ dir

Introduce hir::ExprKind::Let - Take 2

Auto merge of #7568 - dtolnay-contrib:ifletelse, r=llogiq

Downgrade option_if_let_else to nursery

I believe that this lint's loose understanding of ownership (#5822, #6737) makes it unsuitable to be enabled by default in its current state, even as a pedantic lint.

Additionally the lint has known problems with type inference (#6137), though I may be willing to consider this a non-blocker in isolation if it weren't for the ownership false positives.

A fourth false positive involving const fn: #7567.

But on top of these, for me the biggest issue is I basically fully agree with https://github.com/rust-lang/rust-clippy/issues/6137#issuecomment-705605688. In my experience this lint universally makes code worse even when the resulting code does compile.

---

changelog: remove [`option_if_let_else`] from default set of enabled lints

update stderr messages

Improve doc for `can_move_expr_to_closure_no_visit`

Fix tracking of which locals would need to be captured in a closure.
* Captures by sub closures are now considered
* Copy types are correctly borrowed by reference when their value is used
* Fields are no longer automatically borrowed by value
* Bindings in `match` and `let` patterns are now checked to determine how a local is captured

Improve `manual_map`
In some cases check if a borrow made in the scrutinee expression would prevent creating the closure used by `map`

Improve `manual_map` and `map_entry`
Locals which can be partially moved created within the to-be-created closure shouldn't block the use of a closure

Downgrade option_if_let_else to nursery

move Constness into TraitPredicate

Auto merge of #7562 - dswij:filter-next-false-positive, r=xFrednet

Fix false positive on `filter_next`

fixes #7561

changelog: Fix false positive on [`filter_next`] when a method does not implement `Iterator`

Fix false positive on `filter_next`

Add false positive test for iterator method

Auto merge of #87954 - flip1995:clippyup, r=Manishearth

Update Clippy

r? `@Manishearth`

Auto merge of #7560 - xFrednet:7289-configuration-for-every-type-lint, r=camsteffen

Use `avoid-breaking-exported-api` configuration in types module

This PR empowers our lovely `avoid-breaking-exported-api` configuration value to also influence the emission of lints inside the `types` module.

(That's pretty much it, not really a change worthy of writing a fairy tale about. Don't get me wrong, I would love to write a short one, but I sadly need to study now).

---

Closes: rust-lang/rust-clippy#7489
changelog: The `avoid-breaking-exported-api` configuration now also works for [`box_vec`], [`redundant_allocation`], [`rc_buffer`], [`vec_box`], [`option_option`], [`linkedlist`], [`rc_mutex`]

changelog: [`rc_mutex`]: update the lint message to comply with the normal format

---

r? `@camsteffen,` as you implemented the configuration value

cc: `@flip1995,` as we've discussed this change in rust-lang/rust-clippy#7308

Update type UI tests to use private items

Use `avoid_breaking_exported_api` for `types` module lints

Addressed PR reviews regarding code style

Updated lint message for `rc_mutex`

Rollup merge of #87885 - m-ou-se:edition-guide-links, r=rylev

Link to edition guide instead of issues for 2021 lints.

This changes the 2021 lints to not link to github issues, but to the edition guide instead.

Fixes  #86996

Merge commit '7bfc26ec8e7a454786668e7e52ffe527fc649735' into clippyup

Auto merge of #7558 - flip1995:rustup, r=flip1995

Rustup

r? `@ghost`

changelog: none

Bump nightly version -> 2021-08-12

Merge remote-tracking branch 'upstream/master' into rustup

Bless clippy tests.

Auto merge of #7546 - mgeier:patch-1, r=giraffate

similar_names: allow "iter" and "item"

changelog: [`similar_names`] no longer complains about `iter` and `item` being too similar

Auto merge of #7516 - lf-:unwrap-or-default, r=xFrednet

Add `unwrap_or_else_default` lint

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: Add a new [`unwrap_or_else_default`] style lint. This will catch `unwrap_or_else(Default::default)` on Result and Option and suggest `unwrap_or_default()` instead.

Auto merge of #7556 - F3real:no_effect_inclusive_range, r=flip1995

No effect inclusive range

I noticed during last PR that range expression is `ExprKind::Struct` while inclusive range is `ExprKind::Call` which was why it was not handled. This PR adds check for this case.

changelog: [`no_effect]` Report inclusive range in no_effect lint