…s provided by source code

…s, r=ChrisDenton

Avoid closing invalid handles

Documentation for [`HandleOrInvalid`] has this note:

> If holds a handle other than `INVALID_HANDLE_VALUE`, it will close the handle on drop.

Documentation for [`HandleOrNull`] has this note:

> If this holds a non-null handle, it will close the handle on drop.

Currently, both will call `CloseHandle` on their invalid handles as a result of using `OwnedHandle` internally, contradicting the above paragraphs. This PR adds destructors that match the documentation.

``@rustbot`` label A-io O-windows T-libs

[`HandleOrInvalid`]: https://doc.rust-lang.org/std/os/windows/io/struct.HandleOrInvalid.html
[`HandleOrNull`]: https://doc.rust-lang.org/std/os/windows/io/struct.HandleOrNull.html

Make incremental sessions identity no longer depend on the crate names provided by source code

This makes incremental sessions identity no longer depend on the crate names provided by source code, implementing
rust-lang/compiler-team#726.

r? ```@oli-obk```

Fix the conflict problem between the diagnostics fixes of lint `unnecessary_qualification`  and  `unused_imports`

fixes rust-lang#121331

For an `item` that triggers lint unnecessary_qualification, if the `use item` which imports this item is also trigger unused import, fixing the two lints at the same time may lead to the problem that the `item` cannot be found.
This PR will avoid reporting lint unnecessary_qualification when conflict occurs.

r? `@petrochenkov`

…ind-wf, r=lcnr

Fix WF for `AsyncFnKindHelper` in new trait solver

`to_opt_closure_kind` ICEs when it sees placeholders... so don't do that

no test b/c I'm too lazy to write a no-core test for this, but I could be convinced otherwise

r? lcnr

Improve `Step` docs

It [came up on urlo](https://users.rust-lang.org/t/implement-trait-step-in-1-76-0/108204?u=cad97) that the unstable reason string isn't helpful, so just remove it; there's nothing meaningful to add here.

Also makes a couple drive-by improvements to the method docs -- removes incorrect references, changes `forward_checked`'s invariant formulation to match `backward_checked`'s, and adds a helpful corollary that `step_unchecked(a, 0)` is always safe.

preserve span when evaluating mir::ConstOperand

This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).

I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).