| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update target_has_atomic documentation for stabilization
`cfg(target_has_atomic)` was stabilized in #93824, but this small note in the docs was not updated at the time.
|
|
Fix library/std compilation on openbsd.
Fix a minor typo from #95241 which prevented compilation on x86_64-unknown-openbsd.
|
|
Stabilize feature vec_retain_mut on Vec and VecDeque
Closes #90829
|
|
Stabilize thread::is_finished
Closes #90470.
r? `@m-ou-se`
|
|
Fix a minor typo from #95241 which prevented compilation on x86_64-unknown-openbsd.
|
|
jhorstmann:fix-double-drop-of-allocator-in-vec-into-iter, r=oli-obk
Fix double drop of allocator in IntoIter impl of Vec
Fixes #95269
The `drop` impl of `IntoIter` reconstructs a `RawVec` from `buf`, `cap` and `alloc`, when that `RawVec` is dropped it also drops the allocator. To avoid dropping the allocator twice we wrap it in `ManuallyDrop` in the `InttoIter` struct.
Note this is my first contribution to the standard library, so I might be missing some details or a better way to solve this.
|
|
specifically
|
|
|
|
allow arbitrary inherent impls for builtin types in core
Part of https://github.com/rust-lang/compiler-team/issues/487. Slightly adjusted after some talks with `@m-ou-se` about the requirements of `t-libs-api`.
This adds a crate attribute `#![rustc_coherence_is_core]` which allows arbitrary impls for builtin types in core.
For other library crates impls for builtin types should be avoided if possible. We do have to allow the existing stable impls however. To prevent us from accidentally adding more of these in the future, there is a second attribute `#[rustc_allow_incoherent_impl]` which has to be added to **all impl items**. This only supports impls for builtin types but can easily be extended to additional types in a future PR.
This implementation does not check for overlaps in these impls. Perfectly checking that requires us to check the coherence of these incoherent impls in every crate, as two distinct dependencies may add overlapping methods. It should be easy enough to detect if it goes wrong and the attribute is only intended for use inside of std.
The first two commits are mostly unrelated cleanups.
|
|
|
|
Strict Provenance MVP
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
See #95228
|
|
|
|
|
|
fix since field version for termination stabilization
fixes incorrect version fields in stabilization of https://github.com/rust-lang/rust/pull/93840
r? `@ehuss`
|
|
Document Linux kernel handoff in std::io::copy and std::fs::copy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This largely makes the stdlib conform to strict provenance on Ubuntu.
Some hairier things have been left alone for now.
|
|
Some things like the unwinders and system APIs are not fully conformant,
this only covers a lot of low-hanging fruit.
|
|
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
|
|
|
|
Ensure io::Error's bitpacked repr doesn't accidentally impl UnwindSafe
Sadly, I'm not sure how to easily test that we don't impl a trait, though (or can libstd use `where io::Error: !UnwindSafe` or something).
Fixes #95203
|
|
yaahc:termination-stabilization-celebration-station, r=joshtriplett
Stabilize Termination and ExitCode
From https://github.com/rust-lang/rust/issues/43301
This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name, as well as splitting off the `to_i32` method behind its own permanently unstable feature flag.
This PR stabilizes the termination trait with the following signature:
```rust
pub trait Termination {
fn report(self) -> ExitCode;
}
```
The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main.
This PR also stabilizes the following APIs on exit code
```rust
#[derive(Clone, Copy, Debug)]
pub struct ExitCode(_);
impl ExitCode {
pub const SUCCESS: ExitCode;
pub const FAILURE: ExitCode;
}
impl From<u8> for ExitCode { /* ... */ }
```
---
All of the previous blockers have been resolved. The main ones that were resolved recently are:
* The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887))
* Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API, letting us offer full support for platform specific exit code APIs in the future.
* Custom exit codes: We resolved this by adding `From<u8> for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers, as needed.
|
|
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
Show ignore message in console and json output
- Provide ignore the message in console and JSON output
- Modify the ignore message style in the log file
related: #92714
|
|
|
|
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
Fix build on i686-apple-darwin systems
Replace `target_arch = "x86_64"` with `not(target_arch = "aarch64")` so that i686-apple-darwin systems dynamically choose implementation.
|
|
Refactor set_ptr_value as with_metadata_of
Replaces `set_ptr_value` (#75091) with methods of reversed argument order:
```rust
impl<T: ?Sized> *mut T {
pub fn with_metadata_of<U: ?Sized>(self, val: *mut U) -> *mut U;
}
impl<T: ?Sized> *const T {
pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *const U;
}
```
By reversing the arguments we achieve several clarifications:
- The function closely resembles `cast` with an argument to
initialize the metadata. This is easier to teach and answers a long
outstanding question that had restricted cast to `Sized` pointee
targets. See multiples reviews of
<https://github.com/rust-lang/rust/pull/47631>
- The 'object identity', in the form of provenance, is now preserved
from the receiver argument to the result. This helps explain the method as
a builder-style, instead of some kind of setter that would modify
something in-place. Ensuring that the result has the identity of the
`self` argument is also beneficial for an intuition of effects.
- An outstanding concern, 'Correct argument type', is avoided by not
committing to any specific argument type. This is consistent with cast
which does not require its receiver to be a 'raw address'.
Hopefully the usage examples in `sync/rc.rs` serve as sufficient examples of the style to convince the reader of the readability improvements of this style, when compared to the previous order of arguments.
I want to take the opportunity to motivate inclusion of this method _separate_ from metadata API, separate from `feature(ptr_metadata)`. It does _not_ involve the `Pointee` trait in any form. This may be regarded as a very, very light form that does not commit to any details of the pointee trait, or its associated metadata. There are several use cases for which this is already sufficient and no further inspection of metadata is necessary.
- Storing the coercion of `*mut T` into `*mut dyn Trait` as a way to dynamically cast some an arbitrary instance of the same type to a dyn trait instance. In particular, one can have a field of type `Option<*mut dyn io::Seek>` to memorize if a particular writer is seekable. Then a method `fn(self: &T) -> Option<&dyn Seek>` can be provided, which does _not_ involve the static trait bound `T: Seek`. This makes it possible to create an API that is capable of utilizing seekable streams and non-seekable streams (instead of a possible less efficient manner such as more buffering) through the same entry-point.
- Enabling more generic forms of unsizing for no-`std` smart pointers. Using the stable APIs only few concrete cases are available. One can unsize arrays to `[T]` by `ptr::slice_from_raw_parts` but unsizing a custom smart pointer to, e.g., `dyn Iterator`, `dyn Future`, `dyn Debug`, can't easily be done generically. Exposing `with_metadata_of` would allow smart pointers to offer their own `unsafe` escape hatch with similar parameters where the caller provides the unsized metadata. This is particularly interesting for embedded where `dyn`-trait usage can drastically reduce code size.
|
|
On 32-bit systems, fdopendir is called `_fdopendir$INODE64$UNIX2003`.
On 64-bit systems, fdopendir is called `_fdopendir$INODE64`.
|
|
Replace `target_arch = "x86_64"` with `not(target_arch = "aarch64")` so that i686-apple-darwin systems dynamically choose implementation.
|
|
Inline u8::is_utf8_char_boundary
Since Rust beta, Rust is incapable of inlining this function in the following example function.
```rust
pub fn safe_substr_to(s: &str, mut length: usize) -> &str {
loop {
if let Some(s) = s.get(..length) {
return s;
}
length -= 1;
}
}
```
When compiled with beta or nightly compiler on Godbolt with `-C opt-level=3` flag it prints the following assembly.
```asm
example::safe_substr_to:
push r15
push r14
push r12
push rbx
push rax
mov r14, rdi
test rdx, rdx
je .LBB0_8
mov rbx, rdx
mov r15, rsi
mov r12, qword ptr [rip + core::num::<impl u8>::is_utf8_char_boundary@GOTPCREL]
jmp .LBB0_4
.LBB0_2:
je .LBB0_9
.LBB0_3:
add rbx, -1
je .LBB0_8
.LBB0_4:
cmp rbx, r15
jae .LBB0_2
movzx edi, byte ptr [r14 + rbx]
call r12
test al, al
je .LBB0_3
mov r15, rbx
jmp .LBB0_9
.LBB0_8:
xor r15d, r15d
.LBB0_9:
mov rax, r14
mov rdx, r15
add rsp, 8
pop rbx
pop r12
pop r14
pop r15
ret
```
`qword ptr [rip + core::num::<impl u8>::is_utf8_char_boundary@GOTPCREL]` is not inlined. `-C remark=all` outputs the following message:
```
note: /rustc/7bccde19767082c7865a12902fa614ed4f8fed73/library/core/src/str/mod.rs:214:25: inline: _ZN4core3num20_$LT$impl$u20$u8$GT$21is_utf8_char_boundary17hace9f12f5ba07a7fE will not be inlined into _ZN4core3str21_$LT$impl$u20$str$GT$16is_char_boundary17hf2587e9a6b8c5e43E because its definition is unavailable
```
Stable compiler outputs more reasonable code:
```asm
example::safe_substr_to:
mov rcx, rdx
mov rax, rdi
test rdx, rdx
je .LBB0_9
mov rdx, rsi
jmp .LBB0_4
.LBB0_2:
cmp rdx, rcx
je .LBB0_7
.LBB0_3:
add rcx, -1
je .LBB0_9
.LBB0_4:
cmp rcx, rdx
jae .LBB0_2
cmp byte ptr [rax + rcx], -64
jl .LBB0_3
mov rdx, rcx
.LBB0_7:
ret
.LBB0_9:
xor edx, edx
ret
```
|
|
Link to std::io's platform-specific behavior disclaimer
This PR adds some links in standard library documentation to point to https://doc.rust-lang.org/std/io/index.html#platform-specific-behavior.
> ### Platform-specific behavior
>
> Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. This is done to help applications both understand what’s happening under the hood as well as investigate any possibly unclear semantics. Note, however, that this is informative, not a binding contract. The implementation of many of these functions are subject to change over time and may call fewer or more syscalls/library functions.
Many of the `std::fs` APIs already link to this disclaimer when discussing system calls.
|
|
|
|
|
|
|
|
impl From<&[T; N]> and From<&mut [T; N]> for Vec<T>
I really wanted to write:
```rust
fn example(a: impl Into<Vec<u8>>) {}
fn main() {
example(b"raw");
}
```
|
|
Docs: make Vec::from_raw_parts documentation less strict
This is my first PR; be gentle!
In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict, since we don't require `T` to have the same size, just `size_of::<T>() * capacity` to be the same, since that is what results in `Layout::size` being the same in `dealloc`, which is really what matters.
Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts`, which I think is useful advise that could also be mentioned in the docs, so I added that too.
Let me know what you think! :)
|
|
ChayimFriedman2:allow-comparing-vecs-with-different-allocators, r=dtolnay
Allow comparing `Vec`s with different allocators using `==`
See https://stackoverflow.com/q/71021633/7884305.
I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec<T> <=> Vec<U> where T: PartialOrd<U>`).
Does it needs tests?
I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly, and even with other allocators, you pass the allocator to `new_in()` so the compiler usually knows the type).
I think this requires FCP since the impls are already stable.
|
|
Clarify that ManuallyDrop<T> has same layout as T
This PR implements the documentation change under discussion in https://github.com/rust-lang/unsafe-code-guidelines/issues/302. It should not be approved or merged until the discussion there is resolved.
|
