Update Clippy

Delayed Clippy sync

r? `@Manishearth`

Add an intermediate representation to exhaustiveness checking

The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields`, but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information, so we only compute it once at the start.
I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before, and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.

Rustup

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 🤔

( 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 )

changelog: none

Since clippy_utils doesn't depend on the itertools crate anymore, the
lint can't find the path.

Add more tracing instrumentation

I changed or added all this while working on a branch and pulled it out so we can merge it on its own.

Add SOLID targets

This PR introduces new tier 3 targets for [SOLID](https://www.kmckk.co.jp/eng/SOLID/) embedded development platform by Kyoto Microcomputer Co., Ltd.

|          Target name           | `target_arch` | `target_vendor` | `target_os`  |
|--------------------------------|---------------|-----------------|--------------|
| `aarch64-kmc-solid_asp3`       | `aarch64`     | `kmc`           | `solid_asp3` |
| `armv7a-kmc-solid_asp3-eabi`   | `arm`         | `kmc`           | `solid_asp3` |
| `armv7a-kmc-solid_asp3-eabihf` | `arm`         | `kmc`           | `solid_asp3` |

## Related PRs

- [ ] `libc`: https://github.com/rust-lang/libc/pull/2227
- [ ] `cc`: https://github.com/alexcrichton/cc-rs/pull/609

## Non-blocking Issues

- [ ] The target kernel can support `Thread::unpark` directly, but this property is not utilized because the underlying kernel feature is used to implement `Condvar` and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives.
- [ ] The rustc book: The page title "\*-kmc-solid-\*" shows up as "-kmc-solid-" in TOC

## Tier 3 Target Policy

As tier 3 targets, the new targets are required to adhere to [the tier 3 target policy](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy) requirements. This section quotes each requirement in entirety and describes how they are met.

> - A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

See [`src/doc/rustc/src/platform-support/kmc-solid.md`](https://github.com/kawadakk/rust/blob/release-add-solid-support/src/doc/rustc/src/platform-support/kmc-solid.md).

> - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
>     - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

The new target names follow this format: `$ARCH-$VENDOR-$OS-$ABI`, which is already adopted by most existing targets. `$ARCH` and `$ABI` follow the convention: `aarch64-*` for AArch64, `armv7a-*-eabi` for Armv7-A with EABI. `$OS` is used to distinguish multiple variations of the platform in a somewhat similar way to the Apple targets, though we are only adding one variation in this PR. `$VENDOR` denotes the platform vendor name similarly to the Apple, Solaris, SGX, and VxWorks targets.

`$OS` corresponds to the value of `target_os` and takes the format `solid-$KERNEL`. The inclusion of a hyphen prevents unique decomposition of target names, though the mapping between target names and target attributes isn't trivial in the first place, e.g., because of the Android targets.

More targets may be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future.

> - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
>     - The target must not introduce license incompatibilities.
>     - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`).
>     - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
>     - If the target supports building host tools (such as `rustc` or `cargo`), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
>     - Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
>     - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

We intend to make the contribution fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy, and we are willing to ensure this doesn't happen for future contributions regarding the new targets.

The new targets don't support building host tools.

Although the new targets use a platform-provided C compiler toolchain, it can be substituted by [GNU Arm Embedded Toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm) for testing purposes.

> - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for targets that can support dynamic memory allocation, `std` for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

Most features are implemented. The following features are not implemented due to the lack of native support:

- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments

~~Networking is not implemented yet, and we intend to add it as soon as it's ready.~~
Edit (2021-07-07): Networking is now implemented.

Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however.

> - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

See [`src/doc/rustc/src/platform-support/kmc-solid.md`](https://github.com/kawadakk/rust/blob/release-add-solid-support/src/doc/rustc/src/platform-support/kmc-solid.md). Running tests is not supported.

> - Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
>     - This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
> - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ``@`)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
>     - Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
> - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
>     - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

We acknowledge these requirements and intend to ensure they are met.

There are no closely related targets at the moment.

Update changelog to 1.56

As expected a pretty short changelog, because of the missed sync last release cycle.

[Rendered](https://github.com/flip1995/rust-clippy/blob/changelog/CHANGELOG.md)

changelog: none

Auto merge of #89293 - TaKO8Ki:fix-confusing-error-for-path-separator-to-refer-to-an-struct-item, r=estebank

Suggest using the path separator for tuple struct

Fix confusing error message `constructor is not visible here due to private fields` for tuple struct

closes #83450

Use the correct edition for syntax highlighting doctests

Previously it would unconditionally use edition 2015, which was incorrect.

Helps with https://github.com/rust-lang/rust/issues/89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is.

cc `@Mark-Simulacrum`

#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 😄

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.

SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.

# New Targets

The following targets are added:

 - `aarch64-kmc-solid_asp3`
 - `armv7a-kmc-solid_asp3-eabi`
 - `armv7a-kmc-solid_asp3-eabihf`

SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.

More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.

# C Compiler

Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.

# Unresolved Questions

A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.

# Unsupported or Unimplemented Features

Most features are implemented. The following features are not
implemented due to the lack of native support:

- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments

Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.

## Dynamic Linking

Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.

 - The linker invocation used to build the shared object of `std` is
   too long for the platform-provided linker to handle.

 - A linker script with specific requirements is required for the
   compiled shared object to be actually loadable.

As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.

## Executable

Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.

[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/

Improve cause information for NLL higher-ranked errors

This PR has several interconnected pieces:

1. In some of the NLL region error code, we now pass
   around an `ObligationCause`, instead of just a plain `Span`.
   This gets forwarded into `fulfill_cx.register_predicate_obligation`
   during error reporting.
2. The general InferCtxt error reporting code is extended to
   handle `ObligationCauseCode::BindingObligation`
3. A new enum variant `ConstraintCategory::Predicate` is added.
   We try to avoid using this as the 'best blame constraint' - instead,
   we use it to enhance the `ObligationCause` of the `BlameConstraint`
   that we do end up choosing.

As a result, several NLL error messages now contain the same
"the lifetime requirement is introduced here" message as non-NLL
errors.

Having an `ObligationCause` available will likely prove useful
for future improvements to NLL error messages.

Pass real crate-level attributes to `pre_expansion_lint`

The PR concerns the unstable feature `register_tool` (#66079).

The feature's implementation requires the attributes of the crate being compiled, so that when attributes like `allow(foo::bar)` are encountered, it can be verified that `register_tool(foo)` appears in the crate root.

However, the crate's attributes are not readily available during early lint passes. Specifically, on this line, `krate.attrs` appears to be the attributes of the current source file, not the attributes of the whole crate: https://github.com/rust-lang/rust/blob/bf642323d621dcefeef1d8ab4711aae36e357615/compiler/rustc_lint/src/context.rs#L815

Consequently, "unknown tool" errors were being produced when `allow(foo::bar)` appeared in a submodule, even though `register_tool(foo)` appeared in the crate root.

EDITED: The proposed fix is to obtain the real crate-level attributes in `configure_and_expand` and pass them to `pre_expansion_lint`. (See `@petrochenkov's` [comment](https://github.com/rust-lang/rust/pull/89214#issuecomment-926927072) below.)

The original "prosed fix" text follows.

---

The proposed fix is to add an `error_on_unknown_tool` flag to `LintLevelsBuilder`. The flag controls whether "unknown tool" errors are emitted. The flag is set during late passes, but not earlier.

More specifically, this PR contains two commits:

* The first adds a `known-tool-in-submodule` UI test that does not currently pass.
* The second adds the `error_on_unknown_tool` flag. The new test passes with the addition of this flag.

This change has the added benefit of eliminating some errors that were duplicated in existing tests.

To the reviewer: please check that I implemented the UI test correctly.

This shirnks the size of `ConstraintCategory`, hopefully
fixing a performance regression.

This PR has several interconnected pieces:

1. In some of the NLL region error code, we now pass
   around an `ObligationCause`, instead of just a plain `Span`.
   This gets forwarded into `fulfill_cx.register_predicate_obligation`
   during error reporting.
2. The general InferCtxt error reporting code is extended to
   handle `ObligationCauseCode::BindingObligation`
3. A new enum variant `ConstraintCategory::Predicate` is added.
   We try to avoid using this as the 'best blame constraint' - instead,
   we use it to enhance the `ObligationCause` of the `BlameConstraint`
   that we do end up choosing.

As a result, several NLL error messages now contain the same
"the lifetime requirement is introduced here" message as non-NLL
errors.

Having an `ObligationCause` available will likely prove useful
for future improvements to NLL error messages.

Don't normalize opaque types with escaping late-bound regions

Fixes #88862

Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.

Needs a perf run once https://github.com/rust-lang/rustc-perf/pull/1033 is merged

r? `@nikomatsakis`

Suggest both of immutable and mutable trait implementations

closes #85865

bump clippy crates to edition 2021

Also helps with dogfooding edition 2021 a bit. :)
Tests passed locally.

---

changelog: bump edition from 2018 to 2021

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

Clean up clean/types.rs file by making the implementations follow the type declaration

This PR doesn't change anything, it simply moves things around: when reading the code, I realized a few times that a type declaration and implementations on it might be separated by some other type declarations, which makes the reading much more complicated. I put back impl and declaration together.

r? `@camelid`

Simplify explicit request check and allow to run "doc src/librustdoc" even without config set

Originally I wanted to allow the command `doc src/librustdoc` to work when passed explicitly but then `@Mark-Simulacrum` recommended me to generalize it, so here we are!

r? `@Mark-Simulacrum`

Update stdarch submodule

This is mainly to fix the critical issue of aarch64 store intrinsics overwriting additional memory, see https://github.com/rust-lang/stdarch/issues/1220

Changes:
* aarch64/armv7: additional vld1/vst1 intrinsics + perf fixes for existing ones
  * https://github.com/rust-lang/stdarch/pull/1205
  * https://github.com/rust-lang/stdarch/pull/1207
  * https://github.com/rust-lang/stdarch/pull/1216
* armv7: Make FMA work with vfpv4 and optimize
  * https://github.com/rust-lang/stdarch/pull/1219
* Non-visible changes to the testing framework
  * https://github.com/rust-lang/stdarch/pull/1208
  * https://github.com/rust-lang/stdarch/pull/1211
  * https://github.com/rust-lang/stdarch/pull/1213
  * https://github.com/rust-lang/stdarch/pull/1215
  * https://github.com/rust-lang/stdarch/pull/1218

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

Sync rustc_codegen_cranelift

Nothing exciting this time. Mostly internal refactorings.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler

Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.