Merge commit '3ae8faff4d46ad92f194c2a4b941c3152a701b31' into clippyup

remove cfg(bootstrap)

Merge commit '9e3cd88718cd1912a515d26dbd9c4019fd5a9577' into clippyup

Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnr

Implement the new desugaring from `try_trait_v2`

~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix.

`try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277

Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them.  (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.

r? `@ghost`

~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.

Auto merge of #85178 - cjgillot:local-crate, r=oli-obk

Remove CrateNum parameter for queries that only work on local crate

The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.

Using `()` as query key in those cases avoids having to worry about the validity of the query key.

Addressed PR coments

Improve match statements

Show macro name in 'this error originates in macro' message

When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.

Use () for inherent_impls.

Use () for entry_fn.

Use () for HIR queries.

Auto merge of #83813 - cbeuw:remap-std, r=michaelwoerister

Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths

This PR fixes #73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped.

`RealFileName::Named` introduced in #72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path.

`RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure.

When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host".

`rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`.

cc `@eddyb` who implemented `/rustc/...` path devirtualisation

Implement span quoting for proc-macros

This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.

Auto merge of #85109 - RalfJung:remove-const_fn, r=oli-obk

remove const_fn feature gate

Fixes https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`

fix clippy test

Auto merge of #85053 - camsteffen:duplicate-lint, r=davidtwco

Fix duplicate unknown lint errors

Fixes rust-lang/rust-clippy#6602

Fix duplicate unknown lint errors

Fix clippy

Merge commit 'b71f3405606d49b9735606b479c3415a0ca9810f' into clippyup

Use local and remapped paths where appropriate

Auto merge of #84200 - CDirkx:os, r=m-ou-se

Move all `sys::ext` modules to `os`

This PR moves all `sys::ext` modules to `os`, centralizing the location of all `os` code and simplifying the dependencies between `os` and `sys`.

Because this also removes all uses `cfg_if!` on publicly exported items, where after #81969 there were still a few left, this should properly work around https://github.com/rust-analyzer/rust-analyzer/issues/6038.

`@rustbot` label: +T-libs-impl

Auto merge of #83213 - rylev:update-lints-to-errors, r=nikomatsakis

Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021

This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.

r? `@estebank`

Change `std::sys::unix::ext::fs::PermissionsExt::from_mode` to `std::os::imp::unix::fs::PermissionsExt::from_mode` in Clippy

Add ErrorKind::OutOfMemory

Auto merge of #84401 - crlf0710:impl_main_by_path, r=petrochenkov

Implement RFC 1260 with feature_name `imported_main`.

This is the second extraction part of #84062 plus additional adjustments.
This (mostly) implements RFC 1260.

However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.

cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`

Fix clippy error

Auto merge of #84189 - jyn514:clippy-dev, r=Mark-Simulacrum

Implement `x.py test src/tools/clippy --bless`

- Add clippy_dev to the rust workspace

  Before, it would give an error that it wasn't either included or
  excluded from the workspace:

  ```
  error: current package believes it's in a workspace when it's not:
  current:   /home/joshua/rustc/src/tools/clippy/clippy_dev/Cargo.toml
  workspace: /home/joshua/rustc/Cargo.toml

  this may be fixable by adding `src/tools/clippy/clippy_dev` to the `workspace.members` array of the manifest located at: /home/joshua/rustc/Cargo.toml
  Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
  ```

- Change clippy's copy of compiletest not to special-case
  rust-lang/rust. Using OUT_DIR confused `clippy_dev` and it couldn't find
  the test outputs. This is one of the reasons why `cargo dev bless` used
  to silently do nothing (the others were that `CARGO_TARGET_DIR` and
  `PROFILE` weren't set appropriately).

- Run clippy_dev on test failure

I tested this by removing a couple lines from a stderr file, and they
were correctly replaced.

- Fix clippy_dev warnings

Rollup merge of #84484 - jyn514:check-tools, r=Mark-Simulacrum

Don't rebuild rustdoc and clippy after checking bootstrap

This works by unconditionally passing -Z unstable-options to the
compiler. This has no affect in practice since bootstrap doesn't use
`deny(rustc::internal)`.

Fixes https://github.com/rust-lang/rust/issues/82461.

r? ```@Mark-Simulacrum```

Implement RFC 1260 with feature_name `imported_main`.

Switch `rustc::internal` from deny to warn

These should still obey deny-warnings.

Implement `x.py test src/tools/clippy --bless`

- Add clippy_dev to the rust workspace

  Before, it would give an error that it wasn't either included or
  excluded from the workspace:

  ```
  error: current package believes it's in a workspace when it's not:
  current:   /home/joshua/rustc/src/tools/clippy/clippy_dev/Cargo.toml
  workspace: /home/joshua/rustc/Cargo.toml

  this may be fixable by adding `src/tools/clippy/clippy_dev` to the `workspace.members` array of the manifest located at: /home/joshua/rustc/Cargo.toml
  Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
  ```

- Change clippy's copy of compiletest not to special-case
  rust-lang/rust. Using OUT_DIR confused `clippy_dev` and it couldn't find
  the test outputs. This is one of the reasons why `cargo dev bless` used
  to silently do nothing (the others were that `CARGO_TARGET_DIR` and
  `PROFILE` weren't set appropriately).

- Run clippy_dev on test failure

I tested this by removing a couple lines from a stderr file, and they
were correctly replaced.

- Fix clippy_dev warnings

Merge commit '7c7683c8efe447b251d6c5ca6cce51233060f6e8' into clippyup

fix clippy

Merge commit '98e2b9f25b6db4b2680a3d388456d9f95cb28344' into clippyup

fix suggestion for unsized function parameters

Auto merge of #78880 - CDirkx:not_supported, r=joshtriplett

Add `Unsupported` to `std::io::ErrorKind`

I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.

**Implementation**:

The following variant will be added to `std::io::ErrorKind`:

```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.

`decode_error_kind` will be updated  to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`

**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:

> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.

The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.

The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

Fix clippy test using `ErrorKind`

Auto merge of #84064 - hyd-dev:unknown-lints, r=petrochenkov

Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Fixes #83477.

Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Remove #[main] attribute.

Merge commit 'b40ea209e7f14c8193ddfc98143967b6a2f4f5c9' into clippyup

Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov

Use AnonConst for asm! constants

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for `const` operands is still the same as before: `const <expr>`.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.

Use AnonConst for asm! constants

Rollup merge of #83820 - petrochenkov:nolinkargs, r=nagisa

Remove attribute `#[link_args]`

Closes https://github.com/rust-lang/rust/issues/29596

The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.

Remove attribute `#[link_args]`

fix clippy error

Track bound vars

Remove hir::CrateItem.

Remove (lots of) dead code

Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.

Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se

Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

Use iter::zip in src/tools/clippy/

Merge commit '0e87918536b9833bbc6c683d1f9d51ee2bf03ef1' into clippyup

Add has_default to GenericParamDefKind::Const

This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs

Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakis

Stabilize or_patterns (RFC 2535, 2530, 2175)

closes #54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177

update `const_eval_resolve`

clippy: stabilize or_patterns lint

hir: Preserve used syntax in `TyKind::TraitObject`

Auto merge of #82122 - bstrie:dep4real, r=dtolnay

Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated

Fixes #82080.

I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations).

As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.

Auto merge of #83188 - petrochenkov:field, r=lcnr

ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.

Rollup merge of #83092 - petrochenkov:qspan, r=estebank

More precise spans for HIR paths

`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.

This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````

Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis

2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled

This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments

To do so, we

- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code

Closes rust-lang/project-rfc-2229/issues/27
Closes rust-lang/project-rfc-2229/issues/24
r? `@nikomatsakis`

ast: Reduce size of `ExprKind` by boxing fields of `ExprKind::Struct`

ast/hir: Rename field-related structures

StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.

Update clippy tests

Fix error after rebase

Add comments with examples and tests

Use `rustc_interface::interface::Config::parse_sess_created` in Clippy

Add fake_read() to clippy

Clippy: HACK! Fix bootstrap error

This will be removed in the next sync, once beta is at 1.52. Until then
this hack avoids to put `cfg(bootstrap)` into Clippy.

Merge commit '6ed6f1e6a1a8f414ba7e6d9b8222e7e5a1686e42' into clippyup

Auto merge of #79519 - cjgillot:noattr, r=wesleywiser

Store HIR attributes in a side table

Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.

Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.

Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.

~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~

Deprecate items that accidentally weren't deprecated

Fixes #82080

Remove hir::Expr::attrs.

Remove hir::Item::attrs.

Remove hir::ImplItem::attrs.

Remove hir::TraitItem::attrs.

Remove hir::StructField::attrs.

Remove hir::Variant::attrs.

Remove hir::Arm::attrs.

Remove hir::Crate::attrs.

Remove hir::Local::attrs.

Remove hir::StmtKind::attrs.

Do not store attrs in FnKind.

Simplify clippy author.

Switch to changing cp_non_overlap in tform

It was suggested to lower this in MIR instead of ssa, so do that instead.

Update cranelift

Update match branches

This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.

Rollup merge of #82048 - mark-i-m:or-pat-type-ascription, r=petrochenkov

or-patterns: disallow in `let` bindings

~~Blocked on https://github.com/rust-lang/rust/pull/81869~~

Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.

r? ``@petrochenkov``

clippy: fix or-pattern in let binding

Auto merge of #82727 - oli-obk:shrinkmem, r=pnkfelix

Test the effect of shrinking the size of Rvalue by 16 bytes

r? `@ghost`

Rollup merge of #82736 - spastorino:mir-opt-level-perf-changes, r=oli-obk

Bump optimization from mir_opt_level 2 to 3 and 3 to 4 and make "release" be level 2 by default

r? `@oli-obk`

Make clippy set mir_opt_level using Option

Shrink the size of Rvalue by 16 bytes

Fix borrow and deref

Allow noop_method_call in clippy ui test

Use diagnostic items in into_iter_collections

Add missing diagnostic item Symbols

Fix Clippy build and test

Merge commit '928e72dd10749875cbd412f74bfbfd7765dbcd8a' into clippyup