-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 6 pull requests #72021
Merged
Merged
Rollup of 6 pull requests #72021
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
`check_match` creates a new `TypedArena` for every call to `create_and_enter`. DHAT tells me that each `TypedArena` typically is barely used, with typically a single allocation per arena. This commit moves the `TypedArena` creation outwards a bit, into `check_match`, and then passes it into `create_and_enter`. This reduces the number of arenas created by about 4-5x, for a very small perf win. (Moving the arena creation further outwards is hard because `check_match` is a query.)
At this time Apple recommends Bitcode be included for iOS apps, and requires it for tvOS. It is unlikely that a developer would want to disable bitcode when building for these targets, yet by default it will not be generated. This presents a papercut for developers on those platforms. Introduces a new TargetOption boolean key for specific triples to indicate that bitcode should be generated, even if cargo attempts to optimise with -Cembed-bitcode=no.
The App Store performs certain sanity checks on bitcode, including that an acceptable set of command line arguments was used when compiling a given module. For Rust code to be distributed on the app store with bitcode rustc must pretend to have the same command line arguments.
It has a single call site.
The closure isn't necessary.
…, r=kinnison Unify lints handling in rustdoc This is a small cleanup. The goal is to unify a bit things to make the reading simpler. r? @kinnison cc @rust-lang/rustdoc
…r=nikomatsakis Test for zero-sized function items not ICEing Closes rust-lang#30276. Again. Please give rustcake with no icing!
…r=alexcrichton Improve bitcode generation for Apple platforms Some improvements for iOS bitcode support suggested by Alex over at getditto/rust-bitcode#9. r? @alexcrichton This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE). 1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious. 2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section. In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure. Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
…ions-in-check_match, r=oli-obk Reduce `TypedArena` creations in `check_match`. `check_match` creates a new `TypedArena` for every call to `create_and_enter`. DHAT tells me that each `TypedArena` typically is barely used, with typically a single allocation per arena. This commit moves the `TypedArena` creation outwards a bit, into `check_match`, and then passes it into `create_and_enter`. This reduces the number of arenas created by about 4-5x, for a very small perf win. (Moving the arena creation further outwards is hard because `check_match` is a query.) r? @oli-obk
allow wasm target for rustc-ap-rustc_span This fixes rust-lang#71998 by applying the work-a-round. The root cause is probably rust-lang#56935, as @petrochenkov pointed out. I reproduced the bug by: ``` cd ~/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-ap-rustc_span-657.0.0/ cargo build --target wasm32-unknown-unknown ``` Adding this line fixes it.
Work around ICEs during cross-compilation for target, ast, & attr This applies the fix for rust-lang#72003 to work around rust-lang#56935 to three more libraries. With these additional fixes, I'm able to use rustfmt_lib from wasm (rust-lang/rustfmt#4132 (comment)), which was my goal. To get it working locally and to test, I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project: ``` toml [replace] "rustc-ap-rustc_span:656.0.0" = { path = "../rustc-ap-rustc_span" } "rustc-ap-rustc_target:656.0.0" = { path = "../rustc-ap-rustc_target" } "rustc-ap-rustc_ast:656.0.0" = { path = "../rustc-ap-rustc_ast" } "rustc-ap-rustc_attr:656.0.0" = { path = "../rustc-ap-rustc_attr" } ```
@bors r+ rollup=never p=6 |
📌 Commit 827ec49 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
May 8, 2020
⌛ Testing commit 827ec49 with merge 377cb500c3f5eb329dfa7ab20e471d1b88a7bc18... |
💔 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
May 8, 2020
@bors retry |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
May 8, 2020
☀️ Test successful - checks-actions, checks-azure |
This was referenced May 8, 2020
Closed
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:
TypedArena
creations incheck_match
. #71975 (ReduceTypedArena
creations incheck_match
.)Failed merges:
r? @ghost