Add a rustc intrinsic `amdgpu_dispatch_ptr` to access the kernel
dispatch packet on amdgpu.
The HSA kernel dispatch packet contains important information like the
launch size and workgroup size.
The Rust intrinsic lowers to the `llvm.amdgcn.dispatch.ptr` LLVM
intrinsic, which returns a `ptr addrspace(4)`, plus an addrspacecast to
`addrspace(0)`, so it can be returned as a Rust reference.
The returned pointer/reference is valid for the whole program lifetime,
and is therefore `'static`.
The return type of the intrinsic (`*const ()`) does not mention the
struct so that rustc does not need to know the exact struct type.
An alternative would be to define the struct as lang item or add a
generic argument to the function.
Short version:
```rust
#[cfg(target_arch = "amdgpu")]
pub fn amdgpu_dispatch_ptr() -> *const ();
```
Stop emitting UbChecks on every Vec→Slice
Spotted this in rust-lang/rust#148766's test changes. It doesn't seem like this ubcheck would catch anything useful; let's see if skipping it helps perf. (After all, this is inside *every* `[]` on a vec, among other things.)
The documentation of `SipHasher` previously linked to a page about
SipHash on https://131002.net, a domain registered to Jean-Philippe
Aumasson, one of the co-authors of the original SipHash paper (alongside
Daniel J Bernstein).
That domain now redirects to another of Mr Aumasson's domains,
https://www.aumasson.jp, but which does not host a similar page
dedicated to SipHash. Instead, his site links to a GitHub repository
containing a C implementation together with links to the original
research paper. Mr Bernstein's own site, https://cr.yp.to, only hosts a
copy of the research paper.
Therefore the GitHub repository appears to be the most official and
complete reference to which we can link.
Update `literal-escaper` version to `0.0.7`
It removes the `std` dependency for this crate (which doesn't change anything for rustc 😄 ).
cc @bjorn3
r? @Urgau
std: sys: fs: uefi: Implement remove_dir_all
- Using the implementation from sys::fs::common since UEFI does not have a built-in for this functionality.
@rustbot label +O-UEFI
They were introduced back when std_detect was a standalone crate
published to crates.io. The motivation for std_detect_dlsym_getauxval
was to allow using getauxval without dlopen when statically linking
musl, which we now unconditionally do for musl. And for
std_detect_file_io to allow no_std usage, which std_detect now supports
even with that feature enabled as it directly uses libc. This also
prevents accidentally disabling runtime feature detection when using
cargo build -Zbuild-std -Zbuild-std-features=
Similarly to i686 and X86_64 MinGW targets, Rust needs to provide the
right chkstk symbol for AArch64 to avoid relying on the linker to
provide it.
CC https://github.com/rust-lang/rust/issues/150725
On FreeBSD 15, the error code returned in this situation changed. It's
now ENETUNREACH. I think that error code is reasonable, and it's
documented for connect(2), so we should expect that it might be
returned.
use PIDFD_GET_INFO ioctl when available
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case where the child is spawned but we can't get the pid. And pidfd.{try_}wait will be able to return the exit status even after a process has been reaped. At least on newer kernels.
Tracking issue: https://github.com/rust-lang/rust/issues/82971
`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case
where the child is spawned but we can't get the pid.
And `pidfd.{try_}wait` will be able to return the exit status even after a process has been reaped.
At least on newer kernels.
Improve alloc `Vec::retain_mut` performance
Hi,
While reading the rustc source code, I noticed it uses `smallvec` and `thin-vec` in many places. I started reviewing those crates, optimized their `retain_mut` implementation, and then realized they were using the exact same algorithm as `alloc::vec::Vec` with less unsafe So now I’m back here with a PR for the standard library 😂.
In my benchmarks, this version is noticeably faster when `retain_mut` actually removes elements (thanks to fewer pointer operations, it just advances `write_index`), while performing identically to the current implementation when nothing is removed.
Let’s see if bors likes this change or not.
`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).
- Using the implementation from sys::fs::common since UEFI does not have
a built-in for this functionality.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
