x86_64-fortanix-unknown-sgx and wasm32-unknown-unknown still have os == "unknown" because both have libstd

Majority of targets use "unknown" vendor and changing it from "unknown" to omitted doesn't make sense.
From the LLVM docs (https://clang.llvm.org/docs/CrossCompilation.html#target-triple):

>Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture.
>When a parameter is not important, it can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown

…s and vendor values

As discussed in PR rust-lang#78267, for example:

* rust-lang#78267 (comment)
* rust-lang#78267 (comment)

Co-authored-by: Joshua Nelson <[email protected]>

Including llvm-as adds the ability to include assembly language fragments
that can be inlined using LTO.

Per Mark's recommendation at:
rust-lang#78963 (comment)

Note, in the coverage-reports test, the comment about MacOS was wrong.
The setting is based on config.toml llvm `optimize` setting. There
doesn't appear to be any environment variable I can check, and I
don't think we should add one. Testing the binary itself is a more
reliable way to check anyway.

For the coverage-spanview test, I removed the dependency on sed
altogether, which is much less ugly than trying to work around the
MacOS sed differences.

I tested these changes on Linux, Windows, and Mac.

Document what `is_like_windows` and `is_like_msvc` mean in more detail.

The inliner looks if a sanitizer is enabled before considering
`no_sanitize` attribute as possible source of incompatibility.

The MIR inlining could happen in a crate with sanitizer disabled, but
code generation in a crate with sanitizer enabled, thus the attribute
would be incorrectly ignored.

To avoid the issue never inline functions with different `no_sanitize`
attributes.

The information about cold attribute is lost during inlining,
Avoid the issue by never inlining cold functions.

The callee body is already transformed; the condition is always false.

…ens`

The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare.

During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.

Restructured the code a little, to allow getting both the mir::Body and
coverage graph.

Do not call `unwrap` with `signatures` option enabled

Fixes rust-lang#75229
Didn't add a test since I couldn't set `RUST_SAVE_ANALYSIS_CONFIG` even with `rustc-env`.

rustc_parse: Remove optimization for 0-length streams in `collect_tokens`

The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare.

r? ``@Aaron1011``

…andry

Fix and re-enable two coverage tests on MacOS

Note, in the coverage-reports test, the comment about MacOS was wrong.
The setting is based on config.toml llvm `optimize` setting. There
doesn't appear to be any environment variable I can check, and I
don't think we should add one. Testing the binary itself is a more
reliable way to check anyway.

For the coverage-spanview test, I removed the dependency on sed
altogether, which is much less ugly than trying to work around the
MacOS sed differences.

I tested these changes on Linux, Windows, and Mac.

r? ``@tmandry``
FYI ``@wesleywiser``

rustc_target: Change os and vendor values to "none" and "unknown" for some targets

Closes rust-lang#77730
r? ``@ehuss``

rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc`

And document what `is_like_windows` and `is_like_msvc` actually mean in more detail.

Addresses FIXMEs left from rust-lang#71030.
r? ``@nagisa``

…, r=jyn514

Add a test for r# identifiers

I'm not entirely sure I properly ran the test locally (I think so though), waiting for CI to confirm. :)

``@rustbot`` modify labels: T-rustdoc

r? ``@jyn514``

…0.4, r=tmandry

Added some unit tests as requested

As discussed in PR rust-lang#78267, for example:

* rust-lang#78267 (comment)
* rust-lang#78267 (comment)

r? ``@tmandry``
FYI: ``@wesleywiser``

This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.

Never inline C variadics, cold functions, functions with incompatible attributes ...

... and fix generator inlining.

Closes rust-lang#67863.
Closes rust-lang#78859.

Include llvm-as in llvm-tools-preview component

Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.

Normalize function type during validation

During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.

Closes rust-lang#78442.

Fix rustc_ast_pretty print_qpath resulting in invalid macro input

related rust-lang#76874 (third case)

### Issue:

The input for a procedural macro is incorrect, for the rust code:
```rust

mod m {
    pub trait Tr {
        type Ts: super::Tu;
    }
}

trait Tu {
    fn dummy() { }
}

#[may_proc_macro]
fn foo() {
    <T as m::Tr>::Ts::dummy();
}
```
the macro will get the input:
```rust
fn foo() {
    <T as m::Tr>::dummy();
}
```
Thus `Ts` has disappeared.

### Fix:

This is due to invalid pretty print of qpath. This PR fix it.

Implement BTreeMap::retain and BTreeSet::retain

Adds new methods `BTreeMap::retain` and `BTreeSet::retain`.  These are implemented on top of `drain_filter` (rust-lang#70530).

The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in rust-lang#39560 and stabilized in rust-lang#36648.  The docs and tests are also copied from HashMap/HashSet.

The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue rust-lang#79025.  See also rust-lang/rfcs#1338.