-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Closed
Rollup of 12 pull requests #79037
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Archer Zhang <[email protected]>
Signed-off-by: Aman Arora <[email protected]>
Co-authored-by: Dhruv Jauhar <[email protected]>
Co-authored-by: Dhruv Jauhar <[email protected]>
Co-authored-by: Chris Pardy <[email protected]> Co-authored-by: Logan Mosier <[email protected]>
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
…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)
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.
@bors r+ rollup=never p=5 |
📌 Commit d82ad6c has been approved by |
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
⌛ Testing commit d82ad6c with merge 5a13c89b1f1543644eaa7179fd907ff2f8e2b598... |
💔 Test failed - checks-actions |
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
The CI failed because of #78801. The PR also got marked |
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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
unwrap
withsignatures
option enabled #78352 (Do not callunwrap
withsignatures
option enabled)collect_tokens
#78736 (rustc_parse: Remove optimization for 0-length streams incollect_tokens
)is_like_windows
/is_like_msvc
#78959 (rustc_target: Mark UEFI targets asis_like_windows
/is_like_msvc
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup