Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`
Since it's a bit annoying to have different names for the same thing.
My understanding is that this is just internal stuff that is not part of any public API even tough rust-analyzer knows about it.
Continuation of
- https://github.com/rust-lang/rust/pull/139084.
Discovered while investigating
- https://github.com/rust-lang/rust/issues/150514
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
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
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.
`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
- 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>
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> {
```
std: sys: net: uefi: tcp: Initial TcpListener support
Add support for binding and accepting TCP4 connections.
While testing, the following network options were used with QEMU + OVMF: -nic user,hostfwd=tcp::12345-:12345
The default localhost address on qemu seems to be 10.0.2.15.
UEFI spec does not seem to state that the TCP Handle returned by the Accept method has a ServiceBinding Protocol. So have made the ServiceBinding Protocol optional.
cc `@nicholasbishop`
- 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.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
`crate::io::Result` → `io::Result` in most places
I don't know why many places refer to the type as `crate::io::Result` when `crate::io` is already imported.
```
warning: this URL is not a hyperlink
--> library/std/src/sys/pal/windows/mod.rs:337:5
|
337 | /// https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
help: use an automatic link instead
|
337 | /// <https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail>
| + +
```
std: sys: fs: uefi: Ignore "." and ".." when reading directory
- At least in Unix, "." and ".." are not returned as a directory entry. So ignore these in UEFI as well.
- Will also allow using the `remove_dir_all` implementation from `sys/fs/common`.
Enable file locking support for Hurd
like Illumos (rust-lang/rust#148322) and aix (rust-lang/rust#148619), Hurd was missed when originally
introducing locking gates per target OS in rust-lang/rust#132977. building rustc on Hurd was
broken as a result since 1.91.
At least in Unix, "." and ".." are not returned as a directory entry. So
ignore these in UEFI as well.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
xous: fix build due to function and feature name changes
This tracks a rename of `panic_unwind` to `panic-unwind`, as well as the removal of `abort_internal` as a function.
This also fixes an incorrect function name from when `rust_main_thread_not_inlined` was added.
std: sys: fs: uefi: Implement readdir
- Tested on OVMF.
- Add path field to uefi file since this will also be required in
implementing Debug for rust File.
``@rustbot`` label +O-UEFI
Currently, the `std::os::unix::net::UnixStream` docs do not specify that
the SOCK_CLOEXEC flag is set on new sockets. This commit adds a note
clarifying that, in line with the note abuot the `MSG_NOSIGNAL` flag.
like Illumos and AIX, Hurd was missed when originally introducing locking gates
per target OS. building rustc on Hurd was broken as a result since 1.91.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
stdarch subtree update
Subtree update of `stdarch` to 61119062fb.
Created using https://github.com/rust-lang/josh-sync.
r? `@sayantn`
My first josh sync, it lgtm, but let me know if I missed something.
I'm especially looking forward to the amd GPU module, which we want to use for the offload project.
