| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rename `static_mut_ref` lint to `static_mut_refs`.
(cherry picked from commit 408eeae59d35cbcaab2cfb345d24373954e74fc5)
|
|
(cherry picked from commit 6ac035df442a27cf9e99ab4ec25bb6147a700902)
|
|
|
|
|
|
std: thread_local::register_dtor fix proposal for FreeBSD.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage. using instead home made TLS destructor handler `register_dtor_fallback`.
close #120413
|
|
document `FromIterator for Vec` allocation behaviors
[t-libs discussion](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202024-01-24/near/417686526) about #120091 didn't reach a strong consensus, but it was agreed that if we keep the current behavior it should at least be documented even though it is an implementation detail.
The language is intentionally non-committal. The previous (non-existent) documentation permits a lot of implementation leeway and we want retain that. In some cases we even must retain it to be able to rip out some code paths that rely on unstable features.
|
|
Co-authored-by: Josh Stone <cuviper@gmail.com>
|
|
|
|
r=michaelwoerister
add missing potential_query_instability for keys and values in hashmap
From https://github.com/rust-lang/rust/pull/120435#discussion_r1468883787,
These API are also returning iterator, so we need add `potential_query_instability` for them?
|
|
Fix some `Arc` allocator leaks
This doesn't matter for the stable `Global` allocator as it is a ZST singleton, but other allocators may rely on all instances being dropped.
|
|
Revert outdated version of "Add the wasm32-wasi-preview2 target"
An outdated version of #119616 was merged in rollup #120309.
This reverts those changes to enable #119616 to “retain the intended diff” after a rebase.
```@rylev``` has agreed that this would be the cleanest approach with respect to the history.
Unblocks #119616.
r? ```@petrochenkov``` or compiler or libs
|
|
Remove `raw_os_nonzero` feature.
This feature is superseded by a generic `NonZero` type: https://github.com/rust-lang/rust/issues/120257
Closes https://github.com/rust-lang/rust/issues/82363.
|
|
r=ChrisDenton
std: Update documentation of seek_write on Windows
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states:
> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.
This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
|
|
raw pointer metadata API: data address -> data pointer
A pointer consists of [more than just an address](https://github.com/rust-lang/rfcs/pull/3559), so let's not equate "pointer" and "address" in these docs.
|
|
Reject infinitely-sized reads from io::Repeat
These calls would always run out of memory.
Related to #117925
|
|
Handle out of memory errors in io:Read::read_to_end()
#116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi`
----
I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large.
Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone.
While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662).
I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait.
I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail.
This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
|
|
|
|
|
|
|
|
|
|
Clean dead code
Detected by #118257
|
|
r=ChrisDenton
Adjust Behaviour of `read_dir` and `ReadDir` in Windows Implementation: Check Whether Path to Search In Exists
This pull request changes the `read_dir` function's and the `ReadDir` structure's internal implementations for the Windows operating system to make its behaviour more accurate.
It should be noted that `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function when *no matching files can be found*, not necessarily that the path to search in does not exist in the first place. Therefore, directly returning the "The system cannot find the file specified." may not be accurate.
An extra check for whether the path to search in exists is added, returning a constructed `ReadDir` iterator with its handle being an `INVALID_HANDLE_VALUE` returned by the `FindFirstFileW` function if `ERROR_FILE_NOT_FOUND` is indeed the last OS error. The `ReadDir` implementation for the Windows operating system is correspondingly updated to always return `None` if the handle it has is an `INVALID_HANDLE_VALUE` which can only be the case if and only if specifically constructed by the `read_dir` function in the aforementioned conditions.
It should also be noted that `FindFirstFileW` would have returned `ERROR_PATH_NOT_FOUND` if the path to search in does not exist in the first place.
Presumably fixes #120040.
|
|
Improve documentation for [A]Rc::into_inner
General improvements, and also aims to better encourage the reader to actually check out Arc::try_unwrap.
This addresses concerns from https://github.com/rust-lang/rust/issues/106894#issuecomment-1905627234.
Rendered:
|
|
References refer to allocated objects
Partially addresses https://github.com/rust-lang/unsafe-code-guidelines/issues/465
|
|
|
|
|
|
Currently the documentation of `FileExt::seek_write` on Windows
indicates that writes beyond the end of the file leave intermediate
bytes uninitialized. This commentary dates back to the original
inclusion of these functions in #35704 (wow blast from the past!). At
the time the functionality here was implemented using `WriteFile`, but
nowadays the `NtWriteFile` method is used instead. The documentation for
`NtWriteFile` explicitly states:
> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.
This commentary has had a downstream impact in the `system-interface`
crate where it tries to handle this by explicitly writing zeros, but I
don't believe that's necessary any more. I'm sending a PR upstream here
to avoid future confusion and codify that zeros are written in the
intermediate bytes matching what Windows currently provides.
|
|
This doesn't matter for the stable `Global` allocator as it is a ZST
singleton, but other allocators may rely on all instances being dropped.
|
|
This reverts commit 31ecf341250a889ac1154b2cbe3f0b97f9d008c1.
Co-authored-by: Ryan Levick <me@ryanlevick.com>
|
|
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage.
using instead home made TLS destructor handler `register_dtor_fallback`.
close #120413
|
|
Related to #117925
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #118182 (Properly recover from trailing attr in body)
- #119641 (Remove feature not required by `Ipv6Addr::to_cononical` doctest)
- #119957 (fix: correct suggestion arg for impl trait)
- #120386 (ScopeTree: remove destruction_scopes as unused)
- #120398 (Improve handling of numbers in `IntoDiagnosticArg`)
- #120399 (Remove myself from review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove feature not required by `Ipv6Addr::to_cononical` doctest
The feature does not seem to be required by this doctest.
|
|
Boost iterator intersperse(_with) performance
I did some benchmark digging into the `intersperse` and `intersperse_with` code as part of [this discussion](https://internals.rust-lang.org/t/add-iterate-with-separators-iterator-function/18781/13), and as a result I optimized them a bit, without relying on the peekable iterator.
See also [full benchmark repo](https://github.com/nyurik/intersperse_perf)
Benchmarks show near 2x performance improvements with the simple `sum` [benchmarks](https://gist.github.com/nyurik/68b6c9b3d90f0d14746d4186bf8fa1e2):
|
|
|
|
|
|
mark a doctest with UB as no_run
https://github.com/rust-lang/rust/pull/119911 added a doctest with UB. That one shouldn't be run, or else Miri will complain.
|
|
core: add `From<core::ascii::Char>` implementations
Introduce `From<core::ascii::Char>` implementations for all unsigned
numeric types and `char`. This matches the API of `char` type.
Issue: https://github.com/rust-lang/rust/issues/110998
|
|
std: make `HEAP` initializer never inline
The system allocator for Windows calls `init_or_get_process_heap` every time allocating. It generates very much useless code and makes the binary larger. The `HEAP` only needs to initialize once before the main fn.
Concerns:
* I'm not sure if `init` will be properly called in cdylib.
* Do we need to ensure the allocator works if the user enables `no_main`?
* Should we panic if `GetProcessHeap` returns null?
|
|
Rename `pointer` field on `Pin`
A few days ago, I was helping another user create a self-referential type using `PhantomPinned`. However, I noticed an odd behavior when I tried to access one of the type's fields via `Pin`'s `Deref` impl:
```rust
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
```
```rust
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Since the user named their field `pointer`, it conflicts with the `pointer` field on `Pin`, which is public but unstable since Rust 1.60.0 with #93176. On versions from 1.33.0 to 1.59.0, where the field on `Pin` is private, this program compiles and prints `42` as expected.
To avoid this confusing behavior, this PR renames `pointer` to `__pointer`, so that it's less likely to conflict with a `pointer` field on the underlying type, as accessed through the `Deref` impl. This is technically a breaking change for anyone who names their field `__pointer` on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of `unsafe_pin_internals`.
|
|
impl `From<&[T; N]>` for `Cow<[T]>`
Implement `From<&[T; N]>` for `Cow<[T]>` to simplify its usage in the following example.
```rust
fn foo(data: impl Into<Cow<'static, [&'static str]>>) { /* ... */ }
fn main() {
foo(vec!["hello", "world"]);
foo(&["hello", "world"]); // Error: the trait `From<&[&str; 2]>` is not implemented for `Cow<'static, [&'static str]>`
foo(&["hello", "world"] as &[_]); // Explicit convertion into a slice is required
}
```
|
|
stabilise array methods
Closes #76118
Stabilises the remaining array methods
FCP is yet to be carried out for this
There wasn't a clear consensus on the naming, but all the other alternatives had some flaws as discussed in the tracking issue and there was a silence on this issue for a year
|
|
Fix outdated comment on Box
Caught by `@vi` in https://github.com/rust-lang/rust/pull/113960#discussion_r1454278520
|
|
Update `std::io::Error::downcast` return type
and update its doc according to decision made by rust libs-api team in https://github.com/rust-lang/rust/issues/99262#issuecomment-1894246216
|
|
Remove special-case handling of `vec.split_off(0)`
#76682 added special handling to `Vec::split_off` for the case where `at == 0`. Instead of copying the vector's contents into a freshly-allocated vector and returning it, the special-case code steals the old vector's allocation, and replaces it with a new (empty) buffer with the same capacity.
That eliminates the need to copy the existing elements, but comes at a surprising cost, as seen in #119913. The returned vector's capacity is no longer determined by the size of its contents (as would be expected for a freshly-allocated vector), and instead uses the full capacity of the old vector.
In cases where the capacity is large but the size is small, that results in a much larger capacity than would be expected from reading the documentation of `split_off`. This is especially bad when `split_off` is called in a loop (to recycle a buffer), and the returned vectors have a wide variety of lengths.
I believe it's better to remove the special-case code, and treat `at == 0` just like any other value:
- The current documentation states that `split_off` returns a “newly allocated vector”, which is not actually true in the current implementation when `at == 0`.
- If the value of `at` could be non-zero at runtime, then the caller has already agreed to the cost of a full memcpy of the taken elements in the general case. Avoiding that copy would be nice if it were close to free, but the different handling of capacity means that it is not.
- If the caller specifically wants to avoid copying in the case where `at == 0`, they can easily implement that behaviour themselves using `mem::replace`.
Fixes #119913.
|
|
Stabilize `slice_group_by`
Renamed "group by" to "chunk by" a per #80552.
Newly stable items:
* `core::slice::ChunkBy`
* `core::slice::ChunkByMut`
* `[T]::chunk`
* `[T]::chunk_by`
Closes #80552.
|
