Clarify note in `std::sync::LazyLock` example
I doubt most people know what it means, as I did not until a week ago. In the current form, it seems like a `TODO:`.
Update documentation for Arc::from_raw, Arc::increment_strong_count, and Arc::decrement_strong_count to clarify allocator requirement
### Related Issue:
This update addresses parts of the issue raised in [#134242](https://github.com/rust-lang/rust/issues/134242), where Arc's documentation lacks `Global Allocator` safety descriptions for three APIs. And this was confirmed by ```@workingjubilee``` :
> Wait, nevermind. I apparently forgot the `increment_strong_count` is implicitly A = Global. Ugh. Another reason these things are hard to track, unfortunately.
### PR Description
This PR updates the document for the following APIs:
- `Arc::from_raw`
- `Arc::increment_strong_count`
- `Arc::decrement_strong_count`
These APIs currently lack an important piece of documentation: **the raw pointer must point to a block of memory allocated by the global allocator**. This crucial detail is specified in the source code but is not reflected in the documentation, which could lead to confusion or incorrect usage by users.
### Problem:
The following example demonstrates the potential confusion caused by the lack of documentation:
```rust
#![feature(allocator_api)]
use std::alloc::{Allocator,AllocError, Layout};
use std::ptr::NonNull;
use std::sync::Arc;
struct LocalAllocator {
memory: NonNull<u8>,
size: usize,
}
impl LocalAllocator {
fn new(size: usize) -> Self {
Self {
memory: unsafe { NonNull::new_unchecked(&mut 0u8 as *mut u8) },
size,
}
}
}
unsafe impl Allocator for LocalAllocator {
fn allocate(&self, _layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
Ok(NonNull::slice_from_raw_parts(self.memory, self.size))
}
unsafe fn deallocate(&self, _ptr: NonNull<u8>, _layout: Layout) {
}
}
fn main() {
let allocator = LocalAllocator::new(64);
let arc = Arc::new_in(5, &allocator); // Here, allocator could be any non-global allocator
let ptr = Arc::into_raw(arc);
unsafe {
Arc::increment_strong_count(ptr);
let arc = Arc::from_raw(ptr);
assert_eq!(2, Arc::strong_count(&arc)); // Failed here!
}
}
```
[cfg_match] Adjust syntax
A year has passed since the creation of #115585 and the feature, as expected, is not moving forward. Let's change that.
This PR proposes changing the arm's syntax from `cfg(SOME_CONDITION) => { ... }` to `SOME_CODITION => {}`.
```rust
match_cfg! {
unix => {
fn foo() { /* unix specific functionality */ }
}
target_pointer_width = "32" => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
Why? Because after several manual migrations in https://github.com/rust-lang/rust/pull/116342 it became clear, at least for me, that `cfg` prefixes are unnecessary, verbose and redundant.
Again, everything is just a proposal to move things forward. If the shown syntax isn't ideal, feel free to close this PR or suggest other alternatives.
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>
Rollup of 5 pull requests
Successful merges:
- #135497 (fix typo in typenames of pin documentation)
- #135522 (add incremental test for issue 135514)
- #135523 (const traits: remove some known-bug that do not seem to make sense)
- #135535 (Add GUI test for #135499)
- #135541 (Methods of const traits are const)
r? `@ghost`
`@rustbot` modify labels: rollup
fix typo in typenames of pin documentation
I noticed this whilst reading the documentation for pin.
Basically there was just one to many closing angle brackets on the type parameters in the documentation where instead of being `Pin<&mut T>` it was `Pin<&mut T>>`
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
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``
Rollup of 7 pull requests
Successful merges:
- #132397 (Make missing_abi lint warn-by-default.)
- #133807 (ci: Enable opt-dist for dist-aarch64-linux builds)
- #134143 (Convert `struct FromBytesWithNulError` into enum)
- #134338 (Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics)
- #134678 (Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`)
- #135424 (Detect unstable lint docs that dont enable their feature)
- #135520 (Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs)
r? `@ghost`
`@rustbot` modify labels: rollup
Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`
Since https://github.com/rust-lang/reference/pull/1387 and https://github.com/rust-lang/rust/pull/117572, `&raw mut (*p).field`/`addr_of!((*p).field)` is defined to have the same inbounds preconditions as `ptr::offset`/`ptr::byte_offset`. I.e. `&raw const (*p).field` does not require that `p: *const T` point to a full `size_of::<T>()` bytes of memory, only that `p.byte_add(offset_of!(T, field))` is defined.
The old comment "[...] we don't even get to use `&raw const (*entry_ptr).d_name` because that operation requires the full extent of *entry_ptr to be in bounds of the same allocation, which is not necessarily the case here [...]" is now outdated, and the code can be simplified to use `&raw const (*entry_ptr).field`.
-------
There should be no behavior differences from this PR.
The `: *const dirent64` on line 716 and the `const _: usize = mem::offset_of!(dirent64, $field);` and comment on lines 749-751 are just sanity checks and should not affect semantics.
Since the `offset_ptr!` macro is only called three times, and all with the same local variable entry_ptr, I just used the local variable directly in the macro instead of taking it as an input, and renamed the macro to `entry_field_ptr!`.
The whole macro could also be removed and replaced with just using `&raw const (*entry_ptr).field` in the three places, but the comments on the macro seemed worthwhile to keep.
Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics
Combined with [1], this will change the overflowing multiplication operations to return an `extern "C"`-safe type.
Link: https://github.com/rust-lang/compiler-builtins/pull/735 [1]
Convert `struct FromBytesWithNulError` into enum
This PR renames the former `kind` enum from `FromBytesWithNulErrorKind` to `FromBytesWithNulError`, and removes the original struct.
See https://github.com/rust-lang/libs-team/issues/493
## Possible Changes - TBD
* [x] should the new `enum FromBytesWithNulError` derive `Copy`?
* [ ] should there be any new/changed attributes?
* [x] add some more tests
## Problem
One of `CStr` constructors, `CStr::from_bytes_with_nul(bytes: &[u8])` handles 3 cases:
1. `bytes` has one NULL as the last value - creates CStr
2. `bytes` has no NULL - error
3. `bytes` has a NULL in some other position - error
The 3rd case is error that may require lossy conversion, but the 2nd case can easily be handled by the user code. Unfortunately, this function returns an opaque `FromBytesWithNulError` error in both 2nd and 3rd case, so the user cannot detect just the 2nd case - having to re-implement the entire function and bring in the `memchr` dependency.
## Motivating examples or use cases
In [this code](f86d7a8768/varnish-sys/src/vcl/ws.rs (L158)), my FFI code needs to copy user's `&[u8]` into a C-allocated memory blob in a NUL-terminated `CStr` format. My code must first validate if `&[u8]` has a trailing NUL (case 1), no NUL (adds one on the fly - case 2), or NUL in the middle (3rd case - error). I had to re-implement `from_bytes_with_nul` and add `memchr`dependency just to handle the 2nd case.
r? `@Amanieu`
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.
Enforce syntactical stability of const traits in HIR
This PR enforces what I'm calling *syntactical* const stability of traits. In other words, it enforces the ability to name `~const`/`const` traits in trait bounds in various syntax positions in HIR (including in the trait of an impl header). This functionality is analogous to the *regular* item stability checker, which is concerned with making sure that you cannot refer to unstable items by name, and is implemented as an extension of that pass.
This is separate from enforcing the *recursive* const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new `NonConstOp` to the const checker and probably adjusting some logic to deduplicate redundant errors.
However, this check is separate and necessary for making sure that users don't add `~const`/`const` bounds to items when the trait is not const-stable in the first place. I chose to separate enforcing recursive const stability out of this PR to make it easier to review. I'll probably open a follow-up following this one, blocked on this PR.
r? `@RalfJung` cc `@rust-lang/project-const-traits`
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 3 pull requests
Successful merges:
- #135381 (Add an example for `Vec::splice` inserting elements without removing)
- #135451 (Remove code duplication when hashing query result and interning node)
- #135464 (fix ICE with references to infinite structs in consts)
r? `@ghost`
`@rustbot` modify labels: rollup
Add an example for `Vec::splice` inserting elements without removing
This example clearly showcases how `splice` can be used to insert multiple elements efficiently at an index into a vector.
Fixes#135369.
The added example:
> Using `splice` to insert new items into a vector efficiently at a specific position indicated by an empty range:
> ```rust
> let mut v = vec![1, 5];
> let new = [2, 3, 4];
> v.splice(1..1, new);
> assert_eq!(v, [1, 2, 3, 4, 5]);
> ```
`@rustbot` label A-docs A-collections
use a single large catch_unwind in lang_start
I originally planned to use `abort_unwind` but reading the comment in `thread_cleanup` it seems we are deliberately going for slightly nicer error messages here, so this preserves that. It still seems nice to not repeat `catch_unwind` so often.
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.
