-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 8 pull requests #83454
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rollup of 8 pull requests #83454
Conversation
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
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