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>
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>
Rollup of 7 pull requests
Successful merges:
- #135348 (rustdoc-json: Include items in stripped modules in `Crate::paths`.)
- #135365 (Update the explanation for why we use box_new in vec!)
- #135383 (De-abstract tagged ptr and make it covariant)
- #135401 (Remove some empty expected files to fix blessing)
- #135406 (Update unstable lint docs to include required feature attributes)
- #135407 (Deny various clippy lints)
- #135411 (run_make_support: add `#![warn(unreachable_pub)]`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add #[inline] to copy_from_slice
I'm doing cooked things to CGU partitioning for compiler-builtins (https://github.com/rust-lang/rust/pull/135395) and this was the lone symbol in my compiler-builtins rlib that wasn't an intrinsic. Adding `#[inline]` makes it go away.
Perf report indicates a marginal but chaotic effect on compile time, marginal improvement in codegen. As expected.
Rollup of 6 pull requests
Successful merges:
- #129259 (Add inherent versions of MaybeUninit methods for slices)
- #135374 (Suggest typo fix when trait path expression is typo'ed)
- #135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass)
- #135378 (Remove a bunch of diagnostic stashing that doesn't do anything)
- #135397 (compiletest: add erroneous variant to `string_enum`s conversions error)
- #135398 (add more crash tests)
r? `@ghost`
`@rustbot` modify labels: rollup
update and clarify StructuralPartialEq docs
This apparently hasn't been updated when we finalized the current const pattern matching behavior.
Fixes https://github.com/rust-lang/rust/issues/92454 by providing rationale and context in the docs linked from that error message.
Use `NonNull::without_provenance` within the standard library
This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (#135243).
Close#135343
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
proc_macro: Use `ToTokens` trait in `quote` macro
Tracking issues: #130977, #54722
This PR changed `proc_macro::quote!` to use `ToTokens` trait instead of `TokenStream::from`, and migrated test cases from `quote` crate.
r? `@dtolnay`
CC `@tgross35`
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`](2ef84b7da9),
* 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>
Fix `ptr::from_ref` documentation example comment
The comment says that the expression involves no function call, but that was only true for the example above, the example here _does_ contain a function call.
``@rustbot`` label A-docs
Improve prose around `as_slice` example of IterMut
I've removed the cryptic message about not being able to call `&mut self` methods while retaining a shared borrow of the iterator, such as `as_slice` produces. This is just normal borrowing rules and does not seem especially relevant here. I can whip up a replacement if someone thinks it has value.
add missing provenance APIs on NonNull
This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
pub const fn without_provenance(addr: NonZero<usize>) -> Self;
pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn expose_provenance(self) -> NonZero<usize>;
}
```
https://github.com/rust-lang/libs-team/issues/518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc `@rust-lang/libs-api`
Tracking issue: https://github.com/rust-lang/rust/issues/135243
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());
}
```
Impl String::into_chars
Tracking issue - https://github.com/rust-lang/rust/issues/133125
r? `@programmerjake` `@kennytm` `@Amanieu`
This refers to https://github.com/rust-lang/libs-team/issues/268
Before adding tests and creating a tracking issue, I'd like to reach a consensus on the implementation direction and two questions:
1. Whether we'd add a `String::into_char_indices` method also?
2. See inline comment.
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.
[generic_assert] Constify methods used by the formatting system
cc #44838
Starts the "constification" of all the elements required to allow the execution of the formatting system in constant environments.
```rust
const _: () = { panic!("{:?}", 1i32); };
```
Further stuff is blocked by #133999.
Add support for wasm exception handling to Emscripten target
This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
Add doc aliases for `libm` and IEEE names
Searching "fma" in the Rust documentation returns results for `intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add the IEEE name to `sqrt` as well, `squareRoot`.
