I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.

Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.

Fix suggestion of additional `pub` when using `pub pub fn ...`

Fix rust-lang#87694.

Marked as draft to start with because I want to explore doing the same fix for `const const fn` and other repeated-but-valid keywords.

`@rustbot` label A-diagnostics D-invalid-suggestion T-compiler

Lint bare traits in AstConv.

Removing the lint from lowering allows to:
- make lowering querification easier;
- have the lint implementation in only one place.

r? `@estebank`

Show the unused type for `unused_results` lint

I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.

Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.

miri: lift restriction on extern types being the only field in a struct

Fixes rust-lang#91827.

r? ````@RalfJung````

Constify (most) `Option` methods

r? ``@oli-obk``

…h726

Move generator check earlier in inlining.

Inlining into generator may create references to other generators. For instance, inlining `Pin::<&mut from_generator::GenFuture<[generator1]>>::new_unchecked` into `generator2`. This cross reference can then create cycles when computing inlining for `generator1`.

In order to avoid this kind of surprises, we forbid all inlining into generators, and rely on LLVM to do the right thing. The existing `remove-zst-query-cycle` already ICEs in inline-mir mode, so we use it as test.

Split from rust-lang#91743.

…sing, r=Amanieu

builtin_macros: allow external consumers for AsmArgs parsing

As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing

r? ```@Amanieu``` and/or ```@joshtriplett```