| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
UEFI paths can be of 4 types:
1. Absolute Shell Path: Uses shell mappings
2. Absolute Device Path: this is what we want
3: Relative root: path relative to the current root.
4: Relative
Absolute shell path can be identified with `:` and Absolute Device path
can be identified with `/`. Relative root path will start with `\`.
The algorithm is mostly taken from edk2 UEFI shell implementation and is
somewhat simple. Check for the path type in order.
For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to
get a BorrowedDevicePath for the volume.
For Relative paths, we use the current working directory to construct
the new path.
BorrowedDevicePath abstraction is needed to interact with
`EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol
with the lifetime of UEFI shell.
Absolute Shell paths cannot exist if UEFI shell is missing.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
std: lazily allocate the main thread handle
https://github.com/rust-lang/rust/pull/123550 eliminated the allocation of the main thread handle, but at the cost of greatly increased complexity. This PR proposes another approach: Instead of creating the main thread handle itself, the runtime simply remembers the thread ID of the main thread. The main thread handle is then only allocated when it is used, using the same lazy-initialization mechanism as for non-runtime use of `thread::current`, and the `name` method uses the thread ID to identify the main thread handle and return the correct name ("main") for it.
Thereby, we also allow accessing `thread::current` before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from `name` will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
Reverts #123550, CC ``@GnomedDev``
|
|
(*ptr).field` instead of `ptr.offset(...).cast()`.
Also, the macro is only called three times, and all with the same local variable entry_ptr, so just use the local variable directly,
and rename the macro to entry_field_ptr.
|
|
Thereby, we also allow accessing thread::current before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from name will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
|
|
Rollup of 10 pull requests
Successful merges:
- #134498 (Fix cycle error only occurring with -Zdump-mir)
- #134977 (Detect `mut arg: &Ty` meant to be `arg: &mut Ty` and provide structured suggestion)
- #135390 (Re-added regression test for #122638)
- #135393 (uefi: helpers: Introduce OwnedDevicePath)
- #135440 (rm unnecessary `OpaqueTypeDecl` wrapper)
- #135441 (Make sure to mark `IMPL_TRAIT_REDUNDANT_CAPTURES` as `Allow` in edition 2024)
- #135444 (Update books)
- #135450 (Fix emscripten-wasm-eh with unwind=abort)
- #135452 (bootstrap: fix outdated feature name in comment)
- #135454 (llvm: Allow sized-word rather than ymmword in tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
uefi: helpers: Introduce OwnedDevicePath
This PR is split off from #135368 to reduce noise.
No real functionality changes, just some quality of life improvements.
Also implement Debug for OwnedDevicePath for some quality of life
improvements.
|
|
This PR is split off from #135368 to reduce noise.
Rename DevicePath to OwnedDevicePath. This is to allow a non-owning
version of DevicePath in the future to work with UEFI shell APIs which
provide const pointers to device paths for UEFI shell fs mapping.
Also implement Debug for OwnedDevicePath for some quality of life
improvements.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
path: Move is_absolute check to sys::path
I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1].
This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not.
I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases.
[0]: https://github.com/rust-lang/rust/pull/135368
[1]: https://github.com/rust-lang/rust/issues/52331#issuecomment-2492796137
|
|
I am working on fs support for UEFI [0], which similar to windows has prefix
components, but is not quite same as Windows. It also seems that Prefix
is tied closely to Windows and cannot really be extended [1].
This PR just tries to remove coupling between Prefix and absolute path
checking to allow platforms to provide there own implementation to check
if a path is absolute or not.
I am not sure if any platform other than windows currently uses Prefix,
so I have kept the path.prefix().is_some() check in most cases.
[0]: https://github.com/rust-lang/rust/pull/135368
[1]: https://github.com/rust-lang/rust/issues/52331#issuecomment-2492796137
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
|
|
Initial fs module for uefi
- Just a copy of unsupported fs right now to reduce the noise from future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
- This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
|
|
Update a bunch of library types for MCP807
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
r? ghost
|
|
Used pthread name functions returning result for FreeBSD and DragonFly
`pthread_getname_np` and `pthread_setname_np` received a wider adoption in past years and was added to:
* FreeBSD by June 11 2020 via [`2ef84b7da9a6c3e23b4a135e6e863581f16d46e1`](https://github.com/freebsd/freebsd-src/commit/2ef84b7da9a6c3e23b4a135e6e863581f16d46e1),
* DargonFly by March 8 2021 via [`ab5dc9aceb34419d1c4b6006739e61acee8ee999`](https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ab5dc9aceb34419d1c4b6006739e61acee8ee999).
There's not so much advantage except that the result can be checked in debug builds. Ideally it should be unified with Linux' implementation, but it trims the input.
|
|
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
|
|
- Just a copy of unsupported fs right now to reduce the noise from
future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
|
|
Condvar: implement wait_timeout for targets without threads
This always falls back to sleeping since there is no way to notify a condvar on a target without threads.
Even on a target that has no threads the following code is a legitimate use case:
```rust
use std::sync::{Condvar, Mutex};
use std::time::Duration;
fn main() {
let cv = Condvar::new();
let mutex = Mutex::new(());
let mut guard = mutex.lock().unwrap();
cv.notify_one();
let res;
(guard, res) = cv.wait_timeout(guard, Duration::from_secs(3)).unwrap();
assert!(res.timed_out());
}
```
|
|
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
|
|
Add UWP (msvc) target support page
- Added Platform Support page for `x86_64-uwp-windows-msvc`, `i686-uwp-windows-msvc`, `thumbv7a-uwp-windows-msvc` and `aarch64-uwp-windows-msvc`
- Adding myself as a maintainer
- Removing the ticks for `thumbv7a-pc-windows-msvc` and `thumbv7a-uwp-windows-msvc` as they do not currently build due to #134565 and https://github.com/rust-lang/backtrace-rs/pull/685
- Fixed a few minor issues to let most of the UWP targets compile
- Happy new year to all!
r? jieyouxu
|
|
Switch rtems target to panic unwind
Switch the RTEMS target to `panic_unwind`.
Relates to https://github.com/rust-lang/backtrace-rs/pull/682
|
|
Move some things to `std::sync::poison` and reexport them in `std::sync`
Tracking issue: #134646
r? `@tgross35`
I've used `sync_poison_mod` feature flag instead, because `sync_poison` had already been used back in 1.2.
try-job: x86_64-msvc
|
|
|
|
|
|
Align it with musl, which also prefers using lstat() here.
|
|
Since Emscripten uses musl libc internally.
Non-functional change: all LFS64 symbols were aliased to their non-LFS64
counterparts in rust-lang/libc@7c952dceaad4cdc35e00884fcb12a713d41a87e0.
|
|
Unify fs::copy and io::copy on Linux
Currently, `fs::copy` first tries a regular file copy (via copy_file_range) and then falls back to userspace read/write copying. We should use `io::copy` instead as it tries copy_file_range, sendfile, and splice before falling back to userspace copying. This was discovered here: https://github.com/SUPERCILEX/fuc/issues/40
Perf impact: `fs::copy` will now have two additional statx calls to decide which syscall to use. I wonder if we should get rid of the statx calls and only continue down the next fallback when the relevant syscalls say the FD isn't supported.
|
|
Rollup of 8 pull requests
Successful merges:
- #134606 (ptr::copy: fix docs for the overlapping case)
- #134622 (Windows: Use WriteFile to write to a UTF-8 console)
- #134759 (compiletest: Remove the `-test` suffix from normalize directives)
- #134787 (Spruce up the docs of several queries related to the type/trait system and const eval)
- #134806 (rustdoc: use shorter paths as preferred canonical paths)
- #134815 (Sort triples by name in platform_support.md)
- #134816 (tools: fix build failure caused by PR #134420)
- #134819 (Fix mistake in windows file open)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix mistake in windows file open
In #134722 this should have been `c::FileAllocationInfo` not `c::FileEndOfFileInfo`. Oops.
|
|
Windows: Use WriteFile to write to a UTF-8 console
If the console code page is UTF-8 then we can simply write to it without needing to convert to UTF-16 and calling `WriteConsole`.
|
|
Fix renaming symlinks on Windows
Previously we only detected mount points and not other types of links when determining reparse point behaviour.
Also added some tests to avoid this regressing again in the future.
|
|
Previously we only detected mount points and not other types of links when determining reparse point behaviour.
|
|
|
|
Fix forgetting to save statx availability on success
Looks like we forgot to save the statx state on success which means the first failure (common when checking if a file exists) will always require spending an invalid statx to confirm the failure is real.
r? `@thomcc`
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
But fallback to FILE_END_OF_FILE_INFO for WINE
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
r=ChrisDenton
Win: Use POSIX rename semantics for `std::fs::rename` if available
Windows 10 1601 introduced `FileRenameInfoEx` as well as `FILE_RENAME_FLAG_POSIX_SEMANTICS`, allowing for atomic renaming and renaming if the target file is has already been opened with `FILE_SHARE_DELETE`, in which case the file gets renamed on disk while the open file handle still refers to the old file, just like in POSIX. This resolves #123985, where atomic renaming proved difficult to impossible due to race conditions.
If `FileRenameInfoEx` isn't available due to missing support from the underlying filesystem or missing OS support, the renaming is retried with `FileRenameInfo`, which matches the behavior of `MoveFileEx`.
This PR also manually replicates parts of `MoveFileEx`'s internal logic, as reverse-engineered from the disassembly: If the source file is a reparse point and said reparse point is a mount point, the mount point itself gets renamed; otherwise the reparse point is resolved and the result renamed.
Notes:
- Currently, the `win7` target doesn't bother with `FileRenameInfoEx` at all; it's probably desirable to remove that special casing and try `FileRenameInfoEx` anyway if it doesn't exist, in case the binary is run on newer OS versions.
Fixes #123985
|
|
|
|
|
|
r=ChrisDenton
Abstract `ProcThreadAttributeList` into its own struct
As extensively discussed in issue #114854, the current implementation of the unstable `windows_process_extensions_raw_attribute` features lacks support for passing a raw pointer.
This PR wants to explore the opportunity to abstract away the `ProcThreadAttributeList` into its own struct to for one improve safety and usability and secondly make it possible to maybe also use it to spawn new threads.
try-job: x86_64-mingw
|
|
|
|
This always falls back to sleeping since there is no way
to notify a condvar on a target without threads.
|
|
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
|
|
std::net: Solaris supports `SOCK_CLOEXEC` as well since 11.4.
try-job: dist-various-2
|
|
|
|
Run TLS destructors for wasm32-wasip1-threads
The target wasm32-wasip1-threads has support for pthreads and allows registration of TLS destructors.
For spawned threads, this registers Rust TLS destructors by creating a pthreads key with an attached destructor function.
For the main thread, this registers an `atexit` handler to run the TLS destructors.
try-job: test-various
|
|
r=Noratrieb
wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next
When upgrading [Zed](https://github.com/zed-industries/zed/pull/19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773844e7ebf05ccb827c17b7ad9eb28aa295
As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773844e7ebf05ccb827c17b7ad9eb28aa295 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82.
This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
|
