This commit focuses on emitting clean errors for the following syntax
error:

```
Some(42).map(|a|
    dbg!(a);
    a
);
```

Previous implementation tried to recover after parsing the closure body
(the `dbg` expression) by replacing the next `;` with a `,`, which made
the next expression belong to the next function argument. As such, the
following errors were emitted (among others):
  - the semicolon token was not expected,
  - a is not in scope,
  - Option::map is supposed to take one argument, not two.

This commit allows us to gracefully handle this situation by adding
giving the parser the ability to remember when it has just parsed a
closure body inside a function call. When this happens, we can treat the
unexpected `;` specifically and try to parse as much statements as
possible in order to eat the whole block. When we can't parse statements
anymore, we generate a clean error indicating that the braces are
missing, and return an ExprKind::Err.

Fixes rust-lang#87994

It was accidentally changed to use `opts()` in rust-lang#86451.

I also renamed `opts()` to `main_body_opts()` to make this kind of
accidental change less likely.

This fixes odd renderings when these features are used in the first
paragraph of documentation for an item. This is an extension of rust-lang#87270.

this also renders them as `_`, which rustdoc previously did not.

Note that this incorrectly suggests a shared borrow,
but at least we know it's happening.

These were deleted in https://reviews.llvm.org/D108614, and in C++ I
definitely see the argument for their removal. I didn't try and
propagate the changes up into higher layers of rustc in this change
because my initial goal was to get rustc working against LLVM HEAD
promptly, but I'm happy to follow up with some refactoring to make the
API on the Rust side match the LLVM API more directly (though the way
the enum works in Rust makes the API less scary IMO).

r? @nagisa cc @nikic

Otherwise we're kind of reimplementing the inverse of the well-named
methods, and that's not a direction we want to go.

Turns out we can also use Attribute::get*() methods here, and avoid the
AttrBuilder and an extra helper method here.

This usually describes either an error in the compiler itself or some
sort of IO error. Either way, we should report it to the user rather
than just saying "crate not found".

This only gives an error if the crate couldn't be loaded at all - if the
compiler finds another .rlib or .rmeta file which was valid, it will
continue to compile the crate.

Example output:
```
error[E0785]: found invalid metadata files for crate `foo`
 --> bar.rs:3:24
  |
3 |         println!("{}", foo::FOO_11_49[0]);
  |                        ^^^
  |
  = warning: failed to parse rlib '/home/joshua/test-rustdoc/libfoo.rlib': Invalid archive extended name offset
```

 Improve error when an .rlib can't be parsed

This usually describes either an error in the compiler itself or some
sort of IO error. Either way, we should report it to the user rather
than just saying "crate not found".

This only gives an error if the crate couldn't be loaded at all - if the
compiler finds another .rlib or .rmeta file which was valid, it will
continue to compile the crate.

Example output:
```
error[E0785]: found invalid metadata files for crate `foo`
 --> bar.rs:3:24
  |
3 |         println!("{}", foo::FOO_11_49[0]);
  |                        ^^^
  |
  = warning: failed to parse rlib '/home/joshua/test-rustdoc/libfoo.rlib': Invalid archive extended name offset
```

cc `@ehuss`

…races, r=estebank

Emit proper errors when on missing closure braces

This commit focuses on emitting clean errors for the following syntax
error:

```
Some(42).map(|a|
    dbg!(a);
    a
);
```

Previous implementation tried to recover after parsing the closure body
(the `dbg` expression) by replacing the next `;` with a `,`, which made
the next expression belong to the next function argument. As such, the
following errors were emitted (among others):
  - the semicolon token was not expected,
  - a is not in scope,
  - Option::map is supposed to take one argument, not two.

This commit allows us to gracefully handle this situation by adding
giving the parser the ability to remember when it has just parsed a
closure body inside a function call. When this happens, we can treat the
unexpected `;` specifically and try to parse as much statements as
possible in order to eat the whole block. When we can't parse statements
anymore, we generate a clean error indicating that the braces are
missing, and return an ExprKind::Err.

Closes rust-lang#88065.

r? `@estebank`

…erence-to-for-loop-iter, r=nagisa

fix(rustc): suggest `items` be borrowed in `for i in items[x..]`

Fixes rust-lang#87994

Fix issues with Markdown summary options

- Use `summary_opts()` for Markdown summaries
- Enable all main body Markdown options for summaries

…aumeGomez

rustdoc: Fix ICE with `doc(hidden)` on tuple variant fields

Fixes rust-lang#88600.

```rust
pub struct H;
pub struct S;

pub enum FooEnum {
    HiddenTupleItem(#[doc(hidden)] H),
    MultipleHidden(#[doc(hidden)] H, #[doc(hidden)] H),
    MixedHiddenFirst(#[doc(hidden)] H, S),
    MixedHiddenLast(S, #[doc(hidden)] H),
    HiddenStruct {
        #[doc(hidden)]
        h: H,
        s: S,
    },
}
```

Generates
![image](https://user-images.githubusercontent.com/1502855/132259152-382f9517-c2a0-41d8-acd0-64e5993931fc.png)

RustWrapper: avoid deleted unclear attribute methods

These were deleted in https://reviews.llvm.org/D108614, and in C++ I
definitely see the argument for their removal. I didn't try and
propagate the changes up into higher layers of rustc in this change
because my initial goal was to get rustc working against LLVM HEAD
promptly, but I'm happy to follow up with some refactoring to make the
API on the Rust side match the LLVM API more directly (though the way
the enum works in Rust makes the API less scary IMO).

r? `@nagisa` cc `@nikic`

… r=GuillaumeGomez

Allow missing code examples in trait impls.

Excludes Trait implementations from the items that need to have doc code examples when using the `rustdoc::missing_doc_code_examples` lint.

For details see rust-lang#88741

fixes rust-lang#88741

r? `@jyn514`