…illot

More status-quo tests for the `#[coverage(..)]` attribute

Follow-up to rust-lang#126621, after I found even more weird corner-cases in the handling of the coverage attribute.

These tests reveal some inconsistencies that are tracked by rust-lang#126658.

…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#126380 (Add std Xtensa targets support)
 - rust-lang#126636 (Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`s )
 - rust-lang#126659 (More status-quo tests for the `#[coverage(..)]` attribute)
 - rust-lang#126711 (Make Option::as_[mut_]slice const)
 - rust-lang#126717 (Clean up some comments near `use` declarations)
 - rust-lang#126719 (Fix assertion failure for some `Expect` diagnostics.)
 - rust-lang#126730 (Add opaque type corner case test)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#126659 - Zalathar:test-coverage-attr, r=cjgillot

More status-quo tests for the `#[coverage(..)]` attribute

Follow-up to rust-lang#126621, after I found even more weird corner-cases in the handling of the coverage attribute.

These tests reveal some inconsistencies that are tracked by rust-lang#126658.

coverage: Overhaul validation of the `#[coverage(..)]` attribute

This PR makes sweeping changes to how the (currently-unstable) coverage attribute is validated:
- Multiple coverage attributes on the same item/expression are now treated as an error.
- The attribute must always be `#[coverage(off)]` or `#[coverage(on)]`, and the error messages for this are more consistent.
  -  A trailing comma is still allowed after off/on, since that's part of the normal attribute syntax.
- Some places that silently ignored a coverage attribute now produce an error instead.
  - These cases were all clearly bugs.
- Some places that ignored a coverage attribute (with a warning) now produce an error instead.
  - These were originally added as lints, but I don't think it makes much sense to knowingly allow new attributes to be used in meaningless places.
  - Some of these errors might soon disappear, if it's easy to extend recursive coverage attributes to things like modules and impl blocks.

---

One of the goals of this PR is to lay a more solid foundation for making the coverage attribute recursive, so that it applies to all nested functions/closures instead of just the one it is directly attached to.

Fixes rust-lang#126658.

This PR incorporates rust-lang#126659, which adds more tests for validation of the coverage attribute.

`@rustbot` label +A-code-coverage

Rollup merge of rust-lang#126682 - Zalathar:coverage-attr, r=lcnr

coverage: Overhaul validation of the `#[coverage(..)]` attribute

This PR makes sweeping changes to how the (currently-unstable) coverage attribute is validated:
- Multiple coverage attributes on the same item/expression are now treated as an error.
- The attribute must always be `#[coverage(off)]` or `#[coverage(on)]`, and the error messages for this are more consistent.
  -  A trailing comma is still allowed after off/on, since that's part of the normal attribute syntax.
- Some places that silently ignored a coverage attribute now produce an error instead.
  - These cases were all clearly bugs.
- Some places that ignored a coverage attribute (with a warning) now produce an error instead.
  - These were originally added as lints, but I don't think it makes much sense to knowingly allow new attributes to be used in meaningless places.
  - Some of these errors might soon disappear, if it's easy to extend recursive coverage attributes to things like modules and impl blocks.

---

One of the goals of this PR is to lay a more solid foundation for making the coverage attribute recursive, so that it applies to all nested functions/closures instead of just the one it is directly attached to.

Fixes rust-lang#126658.

This PR incorporates rust-lang#126659, which adds more tests for validation of the coverage attribute.

`@rustbot` label +A-code-coverage