`oneshot` Channel
Tracking Issue: https://github.com/rust-lang/rust/issues/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](https://github.com/rust-lang/libs-team/issues/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 https://github.com/rust-lang/rust/pull/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`)
std: sys: fs: uefi: Implement rename
- Using the file_name field in `EFI_FILE_INFO` works for renaming, even when changing directories.
- Does not work for cross-device rename, but that is already expected behaviour according to the docs:
"This will not work if the new name is on a different mount point."
- Also add some helper code for dealing with UefiBox<file::Info>.
- Tested using OVMF in qemu.
- edk2 implementation of the same: 66346d5ede/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c (L455)
``@rustbot`` label +O-UEFI
Update cell.rs, correct module level doc
This change corrects the Cell<T> section by replacing `&mut` with `&` so the statement reads "an &T to the inner value can never be obtained". It also emphasizes that a single &mut T to the inner value can be obtained (e.g. via method core::cell::Cell::get_mut).
MGCA: Support for tuple constructors
r? BoxyUwU
part of https://github.com/rust-lang/rust/issues/132980fixesrust-lang/rust#136379fixesrust-lang/rust#138132
i tried to keep implementation very minimal and it's very similar to how structs was implemented with small adjustments
this does not make const constructor like None works, just something like Some(n)
todo:
* ~~tests~~
* write a better description (not sure if needed)
* add more comments and FIXMEs from structs code
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#149681 (resolve: Split `Scope::Module` into two scopes for non-glob and glob bindings )
- rust-lang/rust#150426 (Update offload test and verify that tgt_(un)register_lib have the right type)
- rust-lang/rust#150678 (relate.rs: tiny cleanup: eliminate temp vars)
r? `@ghost`
`@rustbot` modify labels: rollup
Update offload test and verify that tgt_(un)register_lib have the right type
Apparently, we weren't running offload tests when Enzyme wasn't built. Time to fix that.
Also adds a test mode which generates the host IR, but does not expect device IR/artifacts. This way, we don't have to handle artifacts and paths in our tests.
Also removes some outdated documentation.
cc `@Kevinsala,` `@Sa4dUs`
closes: https://github.com/rust-lang/rust/issues/150415
~~blocked on `needs-offload` infrastructure landing in https://github.com/rust-lang/rust/pull/150427~~
THIR pattern building: Pass HIR nodes instead of loose types/spans
This should make it easier to keep track of where the types/spans came from.
There should be no change to compiler output.
---
In the future I would also like to make more of these lowering methods return `Box<thir::Pat>` instead of `thir::PatKind`, so that it becomes feasible to add more fields to `thir::Pat` (e.g. for https://github.com/rust-lang/rust/pull/150498#discussion_r2652138926). That will be easier if those methods have easy access to the corresponding HIR pattern node, from which they can obtain a type and span.
alloc: Move Cow impl to existing ones
Right now, the `borrow.rs` module starts with a `Cow` impl, although most of them can be found below.
This hurts code readability because there is `ToOwned` alongside its impl directly below it.
Moving it to the others down below makes sense here, given that the entire enum depends on `ToOwned` anyways.
make specialization of `Vec::extend` and `VecDeque::extend_front` work for vec::IntoIter with any `Allocator`, not just `Global`
These functions consume all the elements from the respective collection, but do not care about the `Allocator` they use. Without specifying one (like in `vec::IntoIter<T>`) the specialization is only chosen when `A=Global`.
(extra context: `VecDeque::extend_front` is unstable and tracked by rust-lang/rust#146975)
test: add regression cases for valtree hashing ICE
This PR extends the existing regression test `printing_valtrees_supports_non_values.rs` to cover cases that previously caused an ICE in `const_kind.rs` due to hashing inference variables.
It specifically adds:
A case where an associated constant is used without the required trait bound.
The `0: _` case as suggested in [Here](https://github.com/rust-lang/rust/issues/150409#issuecomment-3700022690)
Fixesrust-lang/rust#150409
Add missing translator resources for interface parse_cfg and parse_check_cfg
Missing resources leads to the failure of `translate_message`.
Fixesrust-lang/rust#150654
Clarify panic conditions in `Iterator::last`
Follow-up PR to rust-lang/rust#150580.
Now `Iterator::last`'s docs specify that it might panic only if the iterator is infinite, rather than if it has more than `usize::MAX` elements.
# Motivation
This is because `Iterator::last`, unlike `count`, also works on iterators with more than `usize::MAX` elements, but could panic on infinite iterators (as in `Repeat`), as discussed in rust-lang/rust#150580.
r? ``@jhpratt``
Forbid generic parameters in types of #[type_const] items
fixesrust-lang/rust#150614
we enforce the same restriction on `#[type_const]` const items that already exists for const generic parameters - when `generic_const_parameter_types` feature gate is not enabled, the type of a `#[type_const]` item cannot reference generic parameters. implementation follows the same pattern used for const generic parameters. we check if the item has the `#[type_const]` attribute and if the feature gate is disabled, then we apply `RibKind::ConstParamTy` restrictions when visiting the type, which prevents the use of generic parameters.
check is added in three places:
- Free const items (`ItemKind::Const`)
- Trait associated consts (`AssocItemKind::Const` in traits)
- Impl associated consts (`AssocItemKind::Const` in impls)
added tests for new feature, hope i get this task right :>
r? `@BoxyUwU`
mutex.rs: remove needless-maybe-unsized bounds
Fixes for:
```text
warning: `?Sized` bound is ignored because of a `Sized` requirement
--> library/std/src/sync/nonpoison/mutex.rs:425:9
|
425 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^
|
note: `T` cannot be unsized because of the bound
--> library/std/src/sync/nonpoison/mutex.rs:425:18
|
425 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^^
= note: ...because `Default` has the bound `Sized`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_maybe_sized
= note: `-W clippy::needless-maybe-sized` implied by `-W clippy::suspicious`
= help: to override `-W clippy::suspicious` add `#[allow(clippy::needless_maybe_sized)]`
help: change the bounds that require `Sized`, or remove the `?Sized` bound
|
425 - impl<T: ?Sized + Default> Default for Mutex<T> {
425 + impl<T: Default> Default for Mutex<T> {
|
warning: `?Sized` bound is ignored because of a `Sized` requirement
--> library/std/src/sync/poison/mutex.rs:691:9
|
691 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^
|
note: `T` cannot be unsized because of the bound
--> library/std/src/sync/poison/mutex.rs:691:18
|
691 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^^
= note: ...because `Default` has the bound `Sized`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_maybe_sized
help: change the bounds that require `Sized`, or remove the `?Sized` bound
|
691 - impl<T: ?Sized + Default> Default for Mutex<T> {
691 + impl<T: Default> Default for Mutex<T> {
```
compiletest: Support revisions in debuginfo (read: debugger) tests
And start using revisions in `tests/debuginfo/macro-stepping.rs` to prevent regressing both with and without `SingleUseConsts` MIR pass.
I recommend commit-by-commit review.
## ~TODO~
- [x] Verify this more carefully.
- [x] Possibly do some preparatory PRs before taking this PR out of draft.
- [x] Rebase on https://github.com/rust-lang/rust/pull/150205 once merged so we don't have to add another "`+ 1`".
## CC
CC ``@Zalathar`` since you might have opinions about that I expose a helper function to reduce duplication
CC ``@saethlin`` since this is what we will use for `tests/debuginfo/basic-stepping.rs` in https://github.com/rust-lang/rust/pull/147426 (in the same way I use it in `tests/debuginfo/macro-stepping.rs` here)
minimal dirfd implementation (1/4)
This is the first of four smaller PRs that will eventually be equivalent to rust-lang/rust#139514.
A few notes:
- I renamed `new` to `open` because `open_dir` takes `&self` and opens a subdirectory.
- I also renamed `open` to `open_file`.
- I'm not sure how to `impl AsRawFd` and friends because the `common` implementation uses `PathBuf`s. How should I proceed here?
The other PRs will be based on this one, so I'll make drafts and mark them ready as their predecessors get merged. They might take a bit though; I've never done this particular thing with git before.
Tracking issue: https://github.com/rust-lang/rust/issues/120426
try-job: aarch64-apple
try-job: dist-various*
try-job: test-various*
try-job: x86_64-msvc-1
try-job: x86_64-mingw*
Add specialization for `deque1.prepend(deque2.drain(range))` (VecDeque::prepend and extend_front)
Tracking issue: rust-lang/rust#146975
This specialization makes sure `deque1.prepend(deque2.drain(..))` gets similar speed to `deque1.append(&mut deque2)`. `deque1.prepend(deque2.drain(..))` is the equivalent of `deque1.append(&mut deque2)` but appending to the front (see the [second example of prepend](https://doc.rust-lang.org/nightly/std/collections/struct.VecDeque.html#method.prepend), prepend is from the same tracking issue).
Fix typo in pattern usefulness documentation
Line 171 introduced and as variable names, but
line 172 incorrectly used . This commit fixes the
inconsistency to use the correct variable names throughout.
Fixesrust-lang/rust#149803
Added codegen tests for different forms of `Option::or`
Adds tests to check the output of the different ways of writing `Option::or`
Fixesrust-lang/rust#124533
