-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 8 pull requests #70211
Merged
Merged
Rollup of 8 pull requests #70211
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
handle that when mir is lowered to llvm-ir more code is generated. landingpads generates 10 llvm-ir instructions and resume 9 llvm-ir instructions.
…e standard library
…sper Prefetch some queries used by the metadata encoder This brings the time for `metadata encoding and writing` for `syntex_syntax` from 1.338s to 0.997s with 6 threads in non-incremental debug mode. r? @Mark-Simulacrum
Update the mir inline costs handle that when mir is lowered to llvm-ir more code is generated. Landingpads generates 10 llvm-ir instructions and resume 9 llvm-ir instructions. r? @wesleywiser
Refactorings to get rid of rustc_codegen_utils r? @eddyb cc rust-lang#45276 After this, the only modules left in `rustc_codegen_utils` are - `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc? - ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate) I don't mind doing either of the above as part of this PR or a followup if you want.
Build dist-android with --enable-profiler This will make the runtime available to enable PGO for Rust code in Firefox on Android. r? @michaelwoerister
…akis rustc_infer: remove InferCtxt::closure_sig as the FnSig is always shallowly known. That is, `ClosureSubsts` is always created (in `rustc_typeck::check::closure`) with a `FnSig`, as the number of inputs is known, even if they might all have inference types. The only useful thing `InferCtxt::closure_sig` was doing is resolving an inference variable used just to get the `ty::FnPtr` containing that `FnSig` into `ClosureSubsts`. The ideal way to solve this would be to add a constructor for `ClosureSubsts`, that combines the parent `Substs`, the closure kind, the signature, and capture types together, but for now I've went with resolving the inference types just after unifying them with the real types. r? @nikomatsakis
hir: replace "items" terminology with "nodes" where appropriate. The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner"). I suspect the naming had something to do with `ItemLocalId`'s use of "item". That is, `ItemLocalId` could be interpreted to mean one of two things: * `IntraItemNodeId` i.e. `IntraOwnerNodeId` * this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR * `IntraOwnerItemId` * this is what `HirOwnerItems` would seem to imply r? @Zoxc cc @michaelwoerister @nikomatsakis
do not 'return' in 'throw_' macros In rust-lang#69839 we turned a closure into a `try` block, but it turns out that does not work with our `throw_` macros, which `return` so they skip the `try`. Here we fix that. For some reason that means we also have to remove some `;`. r? @oli-obk
Update stdarch submodule This only includes one commit: - rust-lang/stdarch@abe96ca (rust-lang/stdarch#842) Fixes rust-lang#68905
@bors r+ p=8 rollup=never |
📌 Commit 744bcc6 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
Mar 21, 2020
☀️ Test successful - checks-azure |
This was referenced Mar 21, 2020
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Mar 21, 2020
Tested on commit rust-lang/rust@98803c1. Direct link to PR: <rust-lang/rust#70211> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
This was referenced Mar 21, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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:
Failed merges:
r? @ghost