The issue:

See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748

Run the above with clippy to see the following warning:

```
warning: returning the result of a `let` binding from a block
  --> src/main.rs:24:5
   |
23 |     let value = Foo::new(&x).value();
   |     --------------------------------- unnecessary `let` binding
24 |     value
   |     ^^^^^
   |
   = note: `#[warn(clippy::let_and_return)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
   |
23 |
24 |     Foo::new(&x).value()
   |
```

Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:

```
error[E0597]: `x` does not live long enough
  --> src/main.rs:23:14
   |
23 |     Foo::new(&x).value()
   |     ---------^^-
   |     |        |
   |     |        borrowed value does not live long enough
   |     a temporary with access to the borrow is created here ...
24 | }
   | -
   | |
   | `x` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
   |
   = note: the temporary is part of an expression at the end of a block;
           consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
   |
23 |     let x = Foo::new(&x).value(); x
   |     ^^^^^^^                     ^^^
```

The fix:

Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.

…=flip1995

clippy_dev: Pass stderr to CommandFailed

This improves error reporting when running `rustfmt` fails for some reason, as seen [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20with.20rustfmt). It will now include the stderr output in the `CliError::CommandFailed` error.

changelog: none

…1995

Do not lint when range is completely included into another one

This fix has been developed following this [comment](rust-lang/rust-clippy#5986 (comment)).
So this will be linted:
```
|----------|
        |-----------|
```
Now this won't be linted:
```
              |---|
|--------------------|
```
and this will still lint:
```
|--------|
|--------------|
```

Fixes: rust-lang#5986

changelog: Fix FPs in match_overlapping_arm, when first arm is completely included in second arm

Implement Rust 2021 panic

This implements the Rust 2021 versions of `panic!()`. See rust-lang#80162 and rust-lang/rfcs#3007.

It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller.

This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: rust-lang@c5273bd That change is blocked on figuring out what to do with rust-lang#80846 first.

exhaustive_structs: don't trigger for structs with private fields

changelog: Restrict `exhaustive_structs` to structs with all-public
fields

Fix let_and_return false positive

The issue:

See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748

Run the above with clippy to see the following warning:

```
warning: returning the result of a `let` binding from a block
  --> src/main.rs:24:5
   |
23 |     let value = Foo::new(&x).value();
   |     --------------------------------- unnecessary `let` binding
24 |     value
   |     ^^^^^
   |
   = note: `#[warn(clippy::let_and_return)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
   |
23 |
24 |     Foo::new(&x).value()
   |
```

Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:

```
error[E0597]: `x` does not live long enough
  --> src/main.rs:23:14
   |
23 |     Foo::new(&x).value()
   |     ---------^^-
   |     |        |
   |     |        borrowed value does not live long enough
   |     a temporary with access to the borrow is created here ...
24 | }
   | -
   | |
   | `x` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
   |
   = note: the temporary is part of an expression at the end of a block;
           consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
   |
23 |     let x = Foo::new(&x).value(); x
   |     ^^^^^^^                     ^^^
```

The fix:

Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.

changelog: none

…ip1995

Add new lint "missing_panics_doc"

fixes rust-lang#1974
changelog: Added the "missing_panics_doc" lint which lints when public functions that may panic are missing "# Panics" in their doc comment

Remove Option from `path_to_res` return type

changelog: none

Tiny cleanup for `path_to_res` to return `Res` instead of `Option<Res>`.

Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.

https://editorconfig.org/

Box the biggest ast::ItemKind variants

This PR is a different approach on rust-lang#81400, aiming to save memory in humongous ASTs.

The three affected item kind enums are:
 - `ast::ItemKind` (208 -> 112 bytes)
 - `ast::AssocItemKind` (176 -> 72 bytes)
 - `ast::ForeignItemKind` (176 -> 72 bytes)

…ion-some-nits, r=flip1995

Updated some NITs in the documentation from rust-lang#6630

I've implemented the two suggestions from rust-lang#6630 that were added after the merge. This PR also changes the example code to use `register_*_pass` instead of `register_late_pass`. I'm not sure if this is better or worse, but it makes it clearer in my opinion. Let me know if I should change it back.

---

changelog: none

r? `@flip1995`

…Simulacrum

Add .editorconfig

This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.

Rustup

Pulling in AST changes

changelog: none

…m-clippy

The following code is supposed to compile

```rust
use std::ops::BitOr;

pub trait IntWrapper {
    type InternalStorage;
}

impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
    Self: Sized,
    T: BitOr + BitOr<Output = T>,
{
    type Output = Self;
    fn bitor(self, _other: Self) -> Self {
        todo!()
    }
}
```

Before this change it would ICE. In rust-lang#70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to  protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.

Fix rust-lang#80207.

The tab replacement for diagnostics added in rust-lang#79757 included a few assertions to
ensure all tab characters are handled appropriately. We've started getting
reports of these assertions firing (rust-lang#81614). Since it's only a cosmetic issue,
this downgrades the assertions to debug only, so we at least continue compiling
even if the diagnostics might be a tad wonky.

Fixes rust-lang#81614

Co-authored-by: eddyb <eddyb@lyken.rs>

make const_err a future incompat lint

This is the first step for rust-lang#71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.

This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a *hard* error (at that point the error-on-use-site can be turned into a `delay_span_bug!` for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).

~~The one annoying effect of this PR is that `let _x = &(1/(1-1));` now also shows the future-incompat warning, even though of course we will *not* make this a hard error. We'll instead (hopefully) stop promoting it -- see rust-lang/rfcs#3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".~~

Cc `@rust-lang/wg-const-eval`

Remove incorrect `delay_span_bug`

The following code is supposed to compile

```rust
use std::ops::BitOr;

pub trait IntWrapper {
    type InternalStorage;
}

impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
    Self: Sized,
    T: BitOr + BitOr<Output = T>,
{
    type Output = Self;
    fn bitor(self, _other: Self) -> Self {
        todo!()
    }
}
```

Before this change it would ICE. In rust-lang#70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to  protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.

Fix (but not close) rust-lang#80207.

Update clippy

r? `@flip1995`

…tebank

Reduce tab formatting assertions to debug only

The tab replacement for diagnostics added in rust-lang#79757 included a few assertions to ensure all tab characters are handled appropriately. We've started getting reports of these assertions firing (rust-lang#81614). Since it's only a cosmetic issue, this downgrades the assertions to debug only, so we at least continue compiling even if the diagnostics might be a tad wonky.

Minimizes the impact of rust-lang#81614

Fix non-existent-field ICE for generic fields.

I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :)

This also changes one the field types in the related test to one that triggered the ICE.

Fixes rust-lang#81627.
Fixes rust-lang#81672.
Fixes rust-lang#81709.

Cc rust-lang#81480 `@b-naber` `@estebank.`