The `asm!` and `global_asm!` macros require their operands to appear
strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`

This is overly strict and can be inconvienent when building complex
`asm!` statements with macros. This PR relaxes the ordering requirements
as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register
operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position.

This approach didn't seem to work well.

…st-lang#49359

+ Add some information to the README.md

After removing the `map_in_place` method, which isn't much use because
modifying every element in a collection such as a `Vec` can be done
trivially with iteration.

Relax ordering rules for `asm!` operands

The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`

This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position after the template strings.

r? `@joshtriplett`

rust-lang#107307 Implementing "<test_binary> --list --format json" for use by IDE test explorers / runners

PR 1 of 2 - wiring up just the new information + implement the command line changes i.e. --format json + tests

upcoming:
PR 2 of 2 - clean up "#[cfg(not(bootstrap))]" from PR 1

As per the discussions on
- MCP: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Implementing.20.22.3Ctest_binary.3E.20--list.20--form.E2.80.A6.20compiler-team.23592/near/328747548
- preRFC: https://internals.rust-lang.org/t/pre-rfc-implementing-test-binary-list-format-json-for-use-by-ide-test-explorers-runners/18308
- FYI on Discord: https://discord.com/channels/442252698964721669/459149169546887178/1075581549409484820

…oot-var, r=lcnr

Canonicalize root var when making response from new solver

During trait solving, if we equate two inference variables `?0` and `?1` but don't equate them with any rigid types, then `InferCtxt::probe_ty_var` will return `Err` for both of these. The canonicalizer code will then canonicalize the variables independently(!), and the response will not reflect the fact that these two variables have been made equal.

This hinders inference and I also don't think it's sound? I haven't thought too much about it past that, so let's talk about it.

r? `@lcnr`

StableMIR: Proof-of-concept implementation + test

This PR is part of the [project Stable MIR](https://github.com/rust-lang/project-stable-mir). The PR deletes old re-exports from rustc_smir and introduces a proof-of-concept implementation for APIs to retrieve crate information.

The implementation follows the [design described here](https://hackmd.io/XhnYHKKuR6-LChhobvlT-g?view), but instead of using separate crates for the implementation, it uses separate modules inside `rustc_smir`.

The API introduced at this point should be seen just as an example on how we are planning to structure the communication between tools and the compiler.

I have not explored yet what should be the right granularity, the best starting point for users, neither the best way to implement it.

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

Simplify `sort_by` calls

small cleanup

Tweak E0740

Also drive-by suppress E0740 if it's an unresolved type.

…, r=BoxyUwU

Suppress copy impl error when post-normalized type references errors

Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization.

----

The const-generics test regressed recently due to rust-lang#107965, cc ````@BoxyUwU.````
 * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails.
 * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.

…-impl-message, r=WaffleLapkin

Tweak illegal `Copy` impl message

The phrase "may not" can both mean "is not able to" and "possibly does not". Disambiguate this by just using "cannot".
`@Lokathor` expressed being annoyed by this [here](https://twitter.com/Lokathor/status/1633200313544089602?s=20).

Also drive-by fix for this extremely noisy message: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a37275bc810f7846bfe191845b7d11d.

r? diagnostics

Rename `MapInPlace` as `FlatMapInPlace`.

After removing the `map_in_place` method, which isn't much use because modifying every element in a collection such as a `Vec` can be done trivially with iteration.

r? `@lqd`

fix: evaluate with wrong obligation stack

fix rust-lang#108897
r? `@lcnr`