-
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 #75510
Merged
Merged
Rollup of 12 pull requests #75510
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
Remove usages of `unwrap` (even when some are safe today).
This reverts commit 2567074. This commit does not actually fix the problem. It merely removes the name of the argument from the LLVM output. Even without the name, Rust codegen still spills the (nameless) variable onto the stack which is the root cause. The root cause is solved in the next commit.
Currently, the code spills operands onto the stack for the purpose of debuginfo. However, naked functions can only contain an asm block. Therefore, attempting to spill the operands on the stack is undefined behavior. Fixes rust-lang#42779 cc rust-lang#32408
Use OK ! like other explanations
While debugging a codegen issue, I tried adding LLVM options with the rustc -Cllvm-args option, and was confused by the error and usage messaging. The LLVM "program name" argument is set to "rustc", and command line error messages make it look like invalid arguments are "rustc" arguments, not LLVM. I changed this argument so error messages and the "-help" usage feedback is easier to understand and react to. (Clang does something similar.)
Correctly parse `{} && false` in tail expression Fix rust-lang#74233, fix rust-lang#54186.
Fix ICE rust-lang#75307 in `format` Remove usages of `unwrap` (even when some are safe today). Fix rust-lang#75307.
Don't spill operands onto the stack in naked functions Currently, the code spills operands onto the stack for the purpose of debuginfo. However, naked functions can only contain an asm block. Therefore, attempting to spill the operands on the stack is undefined behavior. Fixes rust-lang#42779 cc rust-lang#32408 Note that this PR reverts rust-lang#74105 which ultimately didn't fix the problem. cc @haraldh @Amanieu @matthewjasper
…y-keys, r=lcnr self-profile: Cache more query key strings when doing self-profiling. This PR adds optimized `SpecIntoSelfProfilingString` implementations for two common query key types (`LocalDefId` and `WithOptConstParam`). This makes raw self-profiling data on disk 8-9% smaller for my two test cases (`regex` and `cargo`). The on-disk format is not affected, so no tooling updates need to happen. I also tried adding an impl for `Ty<'tcx>` (which should reduce size quite a bit) but the compiler did not allow me to add a specialized impl parameterized with `'tcx`. I don't know if there is an actual problem with that or if the implementation of specialization just doesn't support it yet. cc @wesleywiser @Mark-Simulacrum
fix LocalInfo doc comment The doc comment makes it sound like this is diagnostics-only, but that is not true -- even [unsafety checking uses this information](https://github.com/rust-lang/rust/blob/ded20c98be8585b2a9fe4eeadd1be5524f6ffb17/src/librustc_mir/transform/check_unsafety.rs#L206), so it is crucial for soundness, not just "nice to have". Cc @oli-obk
…trochenkov Remove unused tcx parameter We shouldn't need access to a query context when storing already computed values.
…i-obk Fix E0741 error code explanation Using `ok !` into fixed SRC like in other explanations.
…eywiser Change registered "program name" for -Cllvm-args usage messages While debugging a codegen issue, I tried adding LLVM options with the rustc -Cllvm-args option, and was confused by the error and usage messaging. The LLVM "program name" argument is set to "rustc", and command line error messages make it look like invalid arguments are "rustc" arguments, not LLVM. I changed this argument so error messages and the "-help" usage feedback is easier to understand and react to. (Clang does something similar.) r? @wesleywiser
Expand function pointer docs Be more explicit in the ABI section, and add a section on how to obtain a function pointer, which can be somewhat confusing. Cc rust-lang#75239
…imulacrum make rustc-docs component available to rustup The `rustc-docs` component was generated but not selectable via rustup. Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/rustc.20nightly.20docs.20as.20component.3F r? @Mark-Simulacrum
…ics, r=Mark-Simulacrum Prioritization WG: Open Zulip topics only for `I-prioritize` issues This was discussed in https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/nominations.20and.20other.20automatically.20opened.20topics Is not being helpful to open topics on any of these events and it's even causing more work for the group. @LeSeulArtichaut ... I think this is all that's needed to get rid of this, right?. r? @Mark-Simulacrum cc @rust-lang/wg-prioritization @bors rollup=always
…ulacrum Disable zlib in LLVM on aarch64-apple-darwin For some reason, building rustc on the Apple Silicon DTK fails with some undefined symbols from zlib, which I guess is similar to some issues that appeared on *-apple-ios and *-apple-tvos.
📌 Commit e8acafd 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
Aug 14, 2020
⌛ Testing commit e8acafd with merge b0275f6da8b2d17be1b7373d386bec6795be27f3... |
💔 Test failed - checks-azure |
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
Aug 14, 2020
tmandry
added
the
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
label
Aug 14, 2020
Looks spurious. |
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
Aug 14, 2020
☀️ Test successful - checks-actions, checks-azure |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
merged-by-bors
This PR was explicitly merged by bors.
rollup
A PR which is a rollup
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:
{} && false
in tail expression #74650 (Correctly parse{} && false
in tail expression)format
#75319 (Fix ICE ICE in format macro #75307 informat
)I-prioritize
issues #75496 (Prioritization WG: Open Zulip topics only forI-prioritize
issues)Failed merges:
r? @ghost