Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 12 pull requests #79037

Closed
wants to merge 52 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

JohnTitor and others added 30 commits October 25, 2020 20:52
Co-authored-by: Chris Pardy <[email protected]>
Co-authored-by: Logan Mosier <[email protected]>
Co-authored-by: Jenny Wills <[email protected]>
Co-authored-by: Aman Arora <[email protected]>
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
Including llvm-as adds the ability to include assembly language fragments
that can be inlined using LTO.
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.
tmiasko and others added 19 commits November 12, 2020 20:57
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.
@rustbot rustbot added the rollup A PR which is a rollup label Nov 14, 2020
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Nov 14, 2020

📌 Commit d82ad6c has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 14, 2020
@bors
Copy link
Contributor

bors commented Nov 14, 2020

⌛ Testing commit d82ad6c with merge 5a13c89b1f1543644eaa7179fd907ff2f8e2b598...

@bors
Copy link
Contributor

bors commented Nov 14, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 14, 2020
@arora-aman
Copy link
Member

The CI failed because of #78801. The PR also got marked rollup=never, probably right around when this rollup was created.

@m-ou-se m-ou-se closed this Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.