Rollup of 4 pull requests #150537
Closed
Rollup of 4 pull requests #150537
Conversation
This file contains hidden or 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
The `oneshot` channel is gated under the `oneshot_channel` feature.
Tests inspired by tests in the `oneshot` third-party crate.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Because some AES key scheduling instructions require *either* Zkne or Zknd extension, we must have a target feature to represent `(Zkne || Zknd)`. This commit adds (perma-unstable) target feature to the RISC-V architecture: `zkne_or_zknd` for this purpose. Helped-by: sayantn <sayantn05@gmail.com>
…insics Using the inline assembly and `zkne_or_zknd` target feature could avoid current issues regarding intrinsics available when either Zkne or Zknd is available. Before this commit, intrinsics `aes64ks1i` and `aes64ks2` required both Zkne and Zknd extensions, not either Zkne or Zknd. Closes: rust-lang/stdarch#1765
`oneshot` Channel Tracking Issue: rust-lang#143674 This PR adds an experimental `oneshot` module. Before talking about the API itself, I would prefer to get some of these questions below out of the way first. And as discussed in the [ACP](rust-lang/libs-team#610) it would be # Unresolved Questions - [x] ~~Why exactly is it okay for `Sender` to be `Sync`? Or basically, how do we boil down the discussion in rust-lang#111087 into a comment for the `unsafe impl<T: Send> Sync for Sender<T> {}`?~~ - [x] ~~Why is `mpsc::Receiver` `!Sync` but `mpmc::Receiver` is `Sync`? Should `oneshot::Receiver` be `Sync` or not?~~ - [ ] Should this PR try to add an `is_ready` method as proposed in the tracking issue? If so, then the surface of this PR would likely need to increase to add a `pub(crate) fn is_disconnected` method to `mpmc` (might even be a good idea to add that to all 3 channel flavors). - [ ] In a similar vein to the previous question, should the first internal implementation simply be a wrapper around `mpmc`, or should it be a wrapper around the internal crossbeam implementation? - [ ] Should the `Sender` and `Receiver` operations be methods or associated methods? So `sender.send(msg)` or `Sender::send(sender, msg)`? The method syntax is more consistent with the rest of the ecosystem (namely `tokio`)
…, r=Amanieu RISC-V: Implement (Zkne or Zknd) intrinsics correctly On rust-lang/stdarch#1765, it has been pointed out that two RISC-V (64-bit only) intrinsics to perform AES key scheduling have wrong target feature. `aes64ks1i` and `aes64ks2` instructions require *either* Zkne (scalar cryptography: AES encryption) or Zknd (scalar cryptography: AES decryption) extension (or both) but corresponding Rust intrinsics (in `core::arch::riscv64`) required *both* Zkne and Zknd extensions. An excerpt from the original intrinsics: ```rust #[target_feature(enable = "zkne", enable = "zknd")] ``` To fix that, we need to: 1. Represent a condition where *either* Zkne or Zknd is available and 2. Workaround an issue: `llvm.riscv.aes64ks1i` / `llvm.riscv.aes64ks2` LLVM intrinsics require either Zkne or Zknd extension. This PR attempts to resolve them by: 1. Adding a perma-unstable RISC-V target feature: `zkne_or_zknd` (implied from both `zkne` and `zknd`) and 2. Using inline assembly to construct machine code directly (because `zkne_or_zknd` alone cannot imply neither Zkne nor Zknd, we cannot use LLVM intrinsics). The author confirmed that we can construct an AES key scheduling function with decent performance using fixed `aes64ks1i` and `aes64ks2` intrinsics (with optimization enabled).
docs: fix typo in std::io::buffered
…jackh726 Remove `feature(string_deref_patterns)` The older `string_deref_patterns` feature has been superseded by the newer and more general `deref_patterns` feature. Removing string-deref-patterns allows us to get rid of a few tricky special cases in match lowering, which are different from the special cases used by deref-patterns. The handful of existing tests for `string_deref_patterns` have been migrated to use `deref_patterns` instead. Current nightly users of the older feature should hopefully be able to migrate to the newer feature without too much trouble. Note that `deref_patterns` is currently marked as an “incomplete” feature, because it doesn't have an accepted RFC. But `string_deref_patterns` doesn't appear to have ever had an accepted RFC either, so arguably it should have been marked incomplete too. --- - Tracking issue for both features: rust-lang#87121 - Original implementation: rust-lang#98914 - [Zulip thread: Can we remove `#![feature(string_deref_patterns)]`?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Can.20we.20remove.20.60.23!.5Bfeature.28string_deref_patterns.29.5D.60.3F/with/565787352)
rustbot
added
A-LLVM
Member
Author
|
Rollup of everything. @bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Collaborator
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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:
oneshotChannel #143741 (oneshotChannel)feature(string_deref_patterns)#150530 (Removefeature(string_deref_patterns))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup