Co-authored-by: Archer Zhang <archer.xn@gmail.com>

Signed-off-by: Aman Arora <me@aman-arora.com>

Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com>

Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com>

Co-authored-by: Chris Pardy <chrispardy36@gmail.com>
Co-authored-by: Logan Mosier <logmosier@gmail.com>

Co-authored-by: Chris Pardy <chrispardy36@gmail.com>
Co-authored-by: Logan Mosier <logmosier@gmail.com>

Co-authored-by: Jenny Wills <wills.jenniferg@gmail.com>
Co-authored-by: Aman Arora <me@aman-arora.com>

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 <joshua@yottadb.com>

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)

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`

…akis

RFC-2229: Implement Precise Capture Analysis

### This PR introduces
- Feature gate for RFC-2229 (incomplete) `capture_disjoint_field`
- Rustc Attribute to print out the capture analysis `rustc_capture_analysis`
- Precise capture analysis

### Description of the analysis
1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat)
2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout.
3. To reduce the amount of information we need to keep track of, we do a minimization step. In this step, we determine a list such that no Place within this list represents an ancestor path to another entry in the list.  Check rust-lang/project-rfc-2229#9 for more detailed examples.
4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing.

### Known issues
- Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression.

### Testing
We removed the code that would handle the case where the feature gate is not set, to enable the feature as default and did a bors try and perf run. More information here: rust-lang#78762

### Thanks
This has been slowly in the works for a while now.
I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this, `@nikomatsakis` for guiding us.

Closes rust-lang/project-rfc-2229#7
Closes rust-lang/project-rfc-2229#9
Closes rust-lang/project-rfc-2229#6
Closes rust-lang/project-rfc-2229#19

r? `@nikomatsakis`

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.