This attribute allows to mark default body of a trait function as
unstable. This means that implementing the trait without implementing
the function will require enabling unstable feature.

This is useful in conjunction with `#[rustc_must_implement_one_of]`,
we may want to relax requirements for a trait, for example allowing
implementing either of `PartialEq::{eq, ne}`, but do so in a safe way
-- making implementation of only `PartialEq::ne` unstable.

Because python doesn't have lexical scope, loop variables
persist after the loop is exited, set to the value of the last
itteration

```
>>> i = 0
>>> for i in range(10): pass
...
>>> i
9
```

This causes the `ty` variable to be changed, causing unexpected crashes on
```
pub type RefFn<'a> = &'a dyn for<'b> Fn(&'a i32) -> i32;
```

Closes rust-lang#99118

When an item isn't found, we may suggest an appropriate import to
`use`. Along with that, we also suggest updating the path to work
with the `use`. Unfortunately, if the code in question originates
from a macro, the span used to indicate which part of the path
needs updating may not be suitable and cause an ICE. Since, such
code is not adjustable directly by the user without modifying the
macro, just skip the suggestion in such cases.

…table, r=Aaron1011

Implement `#[rustc_default_body_unstable]`

This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.

`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
    #[rustc_default_body_unstable(feature = "feat", isssue = "none")]
    fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`

This is useful in conjunction with [`#[rustc_must_implement_one_of]`](rust-lang#92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.

r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅

…triddle,GuillaumeGomez

Rustdoc-Json: Document HRTB's on DynTrait

Closes rust-lang#99118

Probably best reviewed commit by commit.

`@rustbot` modify labels: +A-rustdoc-json

cc `@Enselic`

r? `@CraftSpider`

…ackh726

add method to get the mutability of an AllocId

Miri needs this for rust-lang/miri#2463.

…tems, r=lcnr,notriddle,camelid

Don't document impossible to call default trait items on impls

Closes rust-lang#100176

This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.

Don't ICE while suggesting updating item path.

When an item isn't found, we may suggest an appropriate import to `use`. Along with that, we also suggest updating the path to work with the `use`. Unfortunately, if the code in question originates from a macro, the span used to indicate which part of the path needs updating may not be suitable and cause an ICE (*). Since, such code is not adjustable directly by the user without modifying the macro, just skip the suggestion in such cases.

(*) The ICE happens because the emitter want to indicate to the user what code to delete by referencing a certain span. But in this case, said span has `lo == hi == 0` which means it thinks it's a dummy span. Adding a space before the proc macro attribute is enough to stop it from ICE'ing but even then the suggestion doesn't really make any sense:
```
help: if you import `DataStore`, refer to it directly
  |
1 -  #[dbstruct::dbstruct]
1 +  #[dbstruct::dbstruct]
```

Since suggestions are best-effort, I just gated this one on `can_be_used_for_suggestions` which catches cases like this.

Fixes rust-lang#100199

…rsions, r=compiler-errors

Avoid `&str` to `String` conversions

This patch removes the recently added unnecessary `&str` to `String` conversions.

follow-up to rust-lang#99718

…-missing-pattern-excluding-comments, r=compiler-errors

Suggest adding an appropriate missing pattern excluding comments

fixes rust-lang#100272