-
Notifications
You must be signed in to change notification settings - Fork 13k
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 #83454
Rollup of 8 pull requests #83454
Conversation
Co-authored-by: Yuki Okushi <[email protected]>
This change was backed out in rust-lang#83412 so we should remove the reference to it from the release notes.
THis came up in the review of rust-lang#83425: it's hard to imagine a use of LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble when a point release gets created, so let's just discard them to prevent the issue.
stabilize debug_non_exhaustive tracking issue: rust-lang#67364 but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is
Remove Option::{unwrap_none, expect_none}. This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see rust-lang#62633. Closes rust-lang#62633
…c, r=CraftSpider Add documentation for rustdoc-gui tests I think a bit of documentation doesn't hurt in this case considering how "out of the ordinary" this is. r? ``@jyn514``
Add Result::into_err where the Ok variant is the never type Equivalent of rust-lang#66045 but for the inverse situation where `T: Into<!>` rather than `E: Into<!>`. I'm using the same feature gate name. I can't see why one of these methods would be OK to stabilize but not the other. Tracking issue: rust-lang#61695
small cleanups in rustc_errors / emitter This is either moving code around so it gets called less often or using if let instead of match in a few cases.
…-Simulacrum Update RELEASES.md This change was backed out in rust-lang#83412 so we should remove the reference to it from the release notes.
…n514 Use intra-doc link in core::cell ``@rustbot`` label T-doc A-intra-doc-links r? ``@jyn514``
… r=cuviper LLVMWrapper: attractive nuisance macros This came up in the review of rust-lang#83425: it's hard to imagine a use of LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble when a point release gets created, so let's just discard them to prevent the issue.
@bors r+ p=8 rollup=never |
📌 Commit 67436c1 has been approved by |
☀️ Test successful - checks-actions |
📣 Toolstate changed by #83454! Tested on commit 26c7e55. 💔 rls on windows: test-pass → build-fail (cc @Xanewok). |
Tested on commit rust-lang/rust@26c7e55. Direct link to PR: <rust-lang/rust#83454> 💔 rls on windows: test-pass → build-fail (cc @Xanewok). 💔 rls on linux: test-pass → build-fail (cc @Xanewok). 💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro @calebcartwright). 💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro @calebcartwright).
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup