more concrete source url of std docs [V2]
r? jhpratt
since you have reivewed https://github.com/rust-lang/rust/pull/134193
> If someone is looking to contribute, they will want the repository as a whole, not the lib.rs for std.
Now the repository url is reserved, I just add another concrete url as an example, to help people finding target page more quickly&easily.
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
Try to write the panic message with a single `write_all` call
This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single `write_all` call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.
Before:
```
thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs'
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
After:
```
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size
error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
---
try-jobs: x86_64-gnu-llvm-18
Avoid use of LFS64 symbols on Emscripten
Since Emscripten uses musl libc internally.
Non-functional change: all LFS64 symbols were aliased to their non-LFS64 counterparts in rust-lang/libc@7c952dceaa.
Since Emscripten uses musl libc internally.
Non-functional change: all LFS64 symbols were aliased to their non-LFS64
counterparts in rust-lang/libc@7c952dceaa.
char to_digit: avoid unnecessary casts to u64
Hello,
in the `char::to_digit` method there are a few `as u64` casts that are not strictly necessary.
I assume that the reason behind these casts is to avoid possible overflows in the `+ 10` add.
This PR removes the aforementioned casts, avoiding the overflow issue by slightly modifying the ASCII letter to int mapping.
Thanks,
Happy new year.
Tidy up bigint multiplication methods
This tidies up the library version of the bigint multiplication methods after the addition of the intrinsics in #133663. It follows [this summary](https://github.com/rust-lang/rust/issues/85532#issuecomment-2403442775) of what's desired for these methods.
Note that, if `2H = N`, then `uH::MAX * uH::MAX + uH::MAX + uH::MAX` is `uN::MAX`, and that we can effectively add two "carry" values without overflowing.
For ease of terminology, the "low-order" or "least significant" or "wrapping" half of multiplication will be called the low part, and the "high-order" or "most significant" or "overflowing" half of multiplication will be called the high part. In all cases, the return convention is `(low, high)` and left unchanged by this PR, to be litigated later.
## API Changes
The original API:
```rust
impl uN {
// computes self * rhs
pub const fn widening_mul(self, rhs: uN) -> (uN, uN);
// computes self * rhs + carry
pub const fn carrying_mul(self, rhs: uN, carry: uN) -> (uN, uN);
}
```
The added API:
```rust
impl uN {
// computes self * rhs + carry1 + carry2
pub const fn carrying2_mul(self, rhs: uN, carry: uN, add: uN) -> (uN, uN);
}
impl iN {
// note that the low part is unsigned
pub const fn widening_mul(self, rhs: iN) -> (uN, iN);
pub const fn carrying_mul(self, rhs: iN, carry: iN) -> (uN, iN);
pub const fn carrying_mul_add(self, rhs: iN, carry: iN, add: iN) -> (uN, iN);
}
```
Additionally, a naive implementation has been added for `u128` and `i128` since there are no double-wide types for those. Eventually, an intrinsic will be added to make these more efficient, but rather than doing this all at once, the library changes are added first.
## Justifications for API
The unsigned parts are done to ensure consistency with overflowing addition: for a two's complement integer, you want to have unsigned overflow semantics for all parts of the integer except the highest one. This is because overflow for unsigned integers happens on the highest bit (from `MAX` to zero), whereas overflow for signed integers happens on the second highest bit (from `MAX` to `MIN`). Since the sign information only matters in the highest part, we use unsigned overflow for everything but that part.
There is still discussion on the merits of signed bigint *addition* methods, since getting the behaviour right is very subtle, but at least for signed bigint *multiplication*, the sign of the operands does make a difference. So, it feels appropriate that at least until we've nailed down the final API, there should be an option to do signed versions of these methods.
Additionally, while it's unclear whether we need all three versions of bigint multiplication (widening, carrying-1, and carrying-2), since it's possible to have up to two carries without overflow, there should at least be a method to allow that. We could potentially only offer the carry-2 method and expect that adding zero carries afterword will optimise correctly, but again, this can be litigated before stabilisation.
## Note on documentation
While a lot of care was put into the documentation for the `widening_mul` and `carrying_mul` methods on unsigned integers, I have not taken this same care for `carrying_mul_add` or the signed versions. While I have updated the doc tests to be more appropriate, there will likely be many documentation changes done before stabilisation.
## Note on tests
Alongside this change, I've added several tests to ensure that these methods work as expected. These are alongside the codegen tests for the intrinsics.
Fix doc for read&write unaligned in zst operation
### PR Description
This PR addresses an inconsistency in the Rust documentation regarding `read_unaligned ` and `write_unaligned` on zero-sized types (ZSTs). The current documentation for [pointer validity](https://doc.rust-lang.org/nightly/std/ptr/index.html#safety) states that for zero-sized types (ZSTs), null pointers are valid:
> For zero-sized types (ZSTs), every pointer is valid, including the null pointer.
However, there is an inconsistency in the documentation for the unaligned read operation in the function [ptr::read_unaligned](https://doc.rust-lang.org/nightly/std/ptr/fn.read_unaligned.html)(as well as `write_unaligned`), which states:
> Note that even if T has size 0, the pointer must be non-null.
This change is also supported by [PR #134912](https://github.com/rust-lang/rust/pull/134912)
> the _unaligned method docs should be fixed.
Avoid short writes in LineWriter
If the bytes written to `LineWriter` contains at least one new line but doesn't end in a new line (e.g. `"abc\ndef"`) then we:
- write up to the last new line direct to the underlying `Writer`.
- copy as many of the remaining bytes as will fit into our internal buffer.
That last step is inefficient if the remaining bytes are larger than our buffer. It will needlessly split the bytes in two, requiring at least two writes to the underlying `Writer` (one to flush the buffer, one more to write the rest). This PR skips the extra buffering if the remaining bytes are larger than the buffer.
ptr docs: make it clear that we are talking only about memory accesses
This should make it harder to take this sentence out of context and misunderstand it.
stabilize const_swap
libs-api FCP passed in https://github.com/rust-lang/rust/issues/83163.
However, I only just realized that this actually involves an intrinsic. The intrinsic could be implemented entirely with existing stable const functionality, but we choose to make it a primitive to be able to detect more UB. So nominating for `@rust-lang/lang` to make sure they are aware; I leave it up to them whether they want to FCP this.
While at it I also renamed the intrinsic to make the "nonoverlapping" constraint more clear.
Fixes#83163
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.
Add a compiler intrinsic to back `bigint_helper_methods`
cc https://github.com/rust-lang/rust/issues/85532
This adds a new `carrying_mul_add` intrinsic, to implement `wide_mul` and `carrying_mul`.
It has fallback MIR for all types -- including `u128`, which isn't currently supported on nightly -- so that it'll continue to work on all backends, including CTFE.
Then it's overridden in `cg_llvm` to use wider intermediate types, including `i256` for `u128::carrying_mul`.
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
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`.
ptr::copy: fix docs for the overlapping case
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/549
As discussed in that issue, it doesn't make any sense for `copy` to read a byte via `src` after it was already written via `dst`. The entire point of this method is that is copies correctly even if they overlap, and that requires always reading any given location before writing it.
Cc `@rust-lang/opsem`
