about summary refs log tree commit diff
path: root/library/core/src
AgeCommit message (Collapse)AuthorLines
2024-07-10core: Limit remaining f16 doctests to x86_64 linuxUlrich Weigand-0/+15
On s390x, every use of the f16 data type will currently ICE due to https://github.com/llvm/llvm-project/issues/50374, causing doctest failures on the platform. Most doctests were already restricted to certain platforms, so fix this by likewise restricting the remaining five.
2024-07-10size_of_val_raw: for length 0 this is safe to callRalf Jung-0/+10
2024-07-10Rollup merge of #127091 - Sky9x:fused-error-sources-iter, r=dtolnayJacob Pratt-0/+7
impl FusedIterator and a size hint for the error sources iter cc tracking issue #58520
2024-07-08Auto merge of #127235 - martn3:no-mips-f16, r=tgross35,scottmcmbors-6/+9
std: Set `has_reliable_f16` to false for MIPS targets in build.rs This PR makes std tests link for MIPS again (they broke with https://github.com/rust-lang/rust/pull/126608) by avoiding the following link errors. Step-by-step instructions on how to reproduce these errors in docker can be found below. std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17edc3E+0x38): undefined reference to `__gnu_f2h_ieee' std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17hdc3E+0x38): undefined reference to `__gnu_h2f_ieee' This PR just adds one line of config in existing f16 infrastructure. It also disables four doctests that fails with the same link errors. ## Step-by-step to reproduce linking error 1. Prepare: ```sh docker run -it ubuntu:24.10 apt update && apt install -y \ libc6-mips-cross \ libc6-mipsel-cross \ libc6-mips64-cross \ libc6-mips64el-cross \ gcc-mips-linux-gnu \ gcc-mipsel-linux-gnu \ gcc-mips64-linux-gnuabi64 \ gcc-mips64el-linux-gnuabi64 \ git curl python3 build-essential git clone --depth 1 https://github.com/rust-lang/rust.git cd rust ``` 2. Try to link std tests for any of these 4 MIPS targets by running any one of these commands: ```sh CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \ CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \ ./x test library/std --target mips-unknown-linux-gnu CC_mipsel_unknown_linux_gnu=mipsel-linux-gnu-gcc \ CARGO_TARGET_MIPSEL_UNKNOWN_LINUX_GNU_LINKER=mipsel-linux-gnu-gcc \ ./x test library/std --target mipsel-unknown-linux-gnu CC_mips64_unknown_linux_gnuabi64=mips64-linux-gnuabi64-gcc \ CARGO_TARGET_MIPS64_UNKNOWN_LINUX_GNUABI64_LINKER=mips64-linux-gnuabi64-gcc \ ./x test library/std --target mips64-unknown-linux-gnuabi64 CC_mips64el_unknown_linux_gnuabi64=mips64el-linux-gnuabi64-gcc \ CARGO_TARGET_MIPS64EL_UNKNOWN_LINUX_GNUABI64_LINKER=mips64el-linux-gnuabi64-gcc \ ./x test library/std --target mips64el-unknown-linux-gnuabi64 ``` ### Expected No link error. After this PR there are no link errors. ### Actual ``` error: linking with `mips-linux-gnu-gcc` failed: exit status: 1 | = note: LC_ALL="C" PATH="/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "mips-linux-gnu-gcc" "/tmp/rustcEtKsay/symbols.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.00.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.01.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.02.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.03.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.04.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.05.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.06.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.07.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.08.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.09.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.10.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.11.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.13.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.14.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.15.rcgu.o" "-Wl,--as-needed" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_xorshift-deb32232a867c543.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand-5a391600dce9d98f.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_core-a11cfba3d86c5298.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libtest-65b05caf5a9b99a4.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libgetopts-ba692b2f798aef60.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libunicode_width-20ec8b475126cb0b.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/librustc_std_workspace_std-c17f739fee51cc86.rlib" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lstd-124ee57a4c00deda" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/libcompiler_builtins-bd55a137b89bc81f.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib" = note: /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: /rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o: in function `std::num::test_num': std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x38): undefined reference to `__gnu_f2h_ieee' /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x3c): undefined reference to `__gnu_f2h_ieee' /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x44): undefined reference to `__gnu_h2f_ieee' ... collect2: error: ld returned 1 exit status error: could not compile `std` (lib test) due to 1 previous error ```
2024-07-08Rollup merge of #126921 - workingjubilee:outline-va-list, r=Nilstrieb许杰友 Jieyou Xu (Joe)-400/+315
Give VaList its own home Just rearranging things internally and reexporting.
2024-07-07Auto merge of #127454 - matthiaskrgr:rollup-k3vfen2, r=matthiaskrgrbors-1/+15
Rollup of 8 pull requests Successful merges: - #127179 (Print `TypeId` as hex for debugging) - #127189 (LinkedList's Cursor: method to get a ref to the cursor's list) - #127236 (doc: update config file path in platform-support/wasm32-wasip1-threads.md) - #127297 (Improve std::Path's Hash quality by avoiding prefix collisions) - #127308 (Attribute cleanups) - #127354 (Describe Sized requirements for mem::offset_of) - #127409 (Emit a wrap expr span_bug only if context is not tainted) - #127447 (once_lock: make test not take as long in Miri) r? `@ghost` `@rustbot` modify labels: rollup
2024-07-07Rollup merge of #127354 - nicholasbishop:bishop-sized-doc, r=NilstriebMatthias Krüger-0/+14
Describe Sized requirements for mem::offset_of The container doesn't have to be sized, but the field must be sized (at least until https://github.com/rust-lang/rust/issues/126151 is stable).
2024-07-07Rollup merge of #127179 - tgross35:typeid-debug-hex, r=NilstriebMatthias Krüger-1/+1
Print `TypeId` as hex for debugging In <https://github.com/rust-lang/rust/pull/127134>, the `Debug` impl for `TypeId` was changed to print a single integer rather than a tuple. Change this again to print as hex for more concise and consistent formatting, as was suggested. Result: TypeId(0x1378bb1c0a0202683eb65e7c11f2e4d7)
2024-07-07Specialize `TrustedLen` for `Iterator::unzip()`Chayim Refael Friedman-15/+107
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented). I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it. It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`. A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-06Mitigate focused memory leaks in `core` doctests for Miri.Zachary S-0/+6
If/when `-Zmiri-disable-leak-check` is able to be used at test-granularity, it should applied to these tests instead of unleaking.
2024-07-06Remove non-focused memory leaks in `core` doctests for Miri.Zachary S-0/+14
2024-07-06Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes)David Tolnay-4/+4
2024-07-06offset_from intrinsic: always allow pointers to point to the same addressRalf Jung-18/+19
2024-07-06as_simd: fix comment to be in line with 507583a (#121201)Greaka-22/+4
2024-07-06Rollup merge of #127275 - RalfJung:offset-from-isize-min, r=AmanieuMatthias Krüger-265/+118
offset_from, offset: clearly separate safety requirements the user needs to prove from corollaries that automatically follow By landing https://github.com/rust-lang/rust/pull/116675 we decided that objects larger than `isize::MAX` cannot exist in the address space of a Rust program, which lets us simplify these rules. For `offset_from`, we can even state that the *absolute* distance fits into an `isize`, and therefore exclude `isize::MIN`. This PR also changes Miri to treat an `isize::MIN` difference like the other isize-overflowing cases.
2024-07-05Rollup merge of #125751 - pitaj:new_range_api, r=jhprattJubilee-2/+1163
Add `new_range_api` for RFC 3550 Initial implementation for #125687 This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses. This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum. Currently the iterators are just wrappers around the old range types. Tracking issues: - https://github.com/rust-lang/rust/issues/123741 - https://github.com/rust-lang/rust/issues/125687
2024-07-05Rollup merge of #127363 - GuillaumeGomez:improve-fmt-code-readability, r=AmanieuMichael Goulet-7/+15
Improve readability of some fmt code examples Some indent was weird. Some examples were too long (overall better to keep it to maximum 80 columns, but only changed the most outstanding ones). r? ```@Amanieu```
2024-07-05Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelixMichael Goulet-1/+0
Improve dead code analysis Fixes #120770 1. check impl items later if self ty is private although the trait method is public, cause we must use the ty firstly if it's private 2. mark the adt live if it appears in pattern, like generic argument, this implies the use of the adt 3. based on the above, we can handle the case that private adts impl Default, so that we don't need adding rustc_trivial_field_reads on Default, and the logic in should_ignore_item r? ``@pnkfelix``
2024-07-05add `new_range_api` for RFC 3550Peter Jaszkowiak-2/+1163
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the assertion is unlikely to be a problem in practice. This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum. Currently the iterators are just wrappers around the old range types, and most other trait impls delegate to the old rage types as well. Also includes an `.iter()` shorthand for `.clone().into_iter()`
2024-07-05Improve readability of some fmt code examplesGuillaume Gomez-7/+15
2024-07-05Describe Sized requirements for mem::offset_ofNicholas Bishop-0/+14
The container doesn't have to be sized, but the field must be sized (at least until https://github.com/rust-lang/rust/issues/126151 is stable).
2024-07-04impl FusedIterator and a size hint for the error sources iterSky-0/+7
2024-07-04core: erase redundant stability attrs in va_listJubilee Young-106/+0
Now that VaList, et al. have a module, they only need one `#[unstable]`.
2024-07-04library: outline VaList into ffi::va_listJubilee Young-400/+421
and reexport
2024-07-05Auto merge of #126171 - RalfJung:simd_bitmask_multibyte, r=workingjubileebors-6/+13
simd_bitmask intrinsic: add a non-power-of-2 multi-byte example r? `@calebzulawski` `@workingjubilee`
2024-07-04Document safety of a few intrinsicsCelina G. Val-2/+16
2024-07-04Move a few intrinsics to use Rust abiCelina G. Val-57/+146
Move a few more intrinsic functions to the convention added in #121192 where they have Rust abi but are tagged with `rustc_intrinsic`.
2024-07-04mark `can_not_overflow` as `#[rustc_const_stable(...)]`Bennet Bleßmann-2/+1
see https://github.com/rust-lang/rust/pull/124941#discussion_r1664676739
2024-07-04stabilize `const_int_from_str`Skgland-4/+5
2024-07-04Improve dead code analysismu001999-1/+0
2024-07-04also remove redundant requirements from offset()Ralf Jung-196/+100
2024-07-04offset_from: "the difference must fit in an isize" is a corollaryRalf Jung-70/+19
also, isize::MIN is an impossible distance
2024-07-04chore: remove repeat wordscuishuang-2/+2
Signed-off-by: cuishuang <imcusg@gmail.com>
2024-07-04Auto merge of #127226 - mat-1:optimize-siphash-round, r=nnethercotebors-5/+6
Optimize SipHash by reordering compress instructions This PR optimizes hashing by changing the order of instructions in the sip.rs `compress` macro so the CPU can parallelize it better. The new order is taken directly from Fig 2.1 in [the SipHash paper](https://eprint.iacr.org/2012/351.pdf) (but with the xors moved which makes it a little faster). I attempted to optimize it some more after this, but I think this might be the optimal instruction order. Note that this shouldn't change the behavior of hashing at all, only statements that don't depend on each other were reordered. It appears like the current order hasn't changed since its [original implementation from 2012](https://github.com/rust-lang/rust/commit/fada46c4214f26dbdc0fd150a713aced476e75b5#diff-b751133c229259d7099bbbc7835324e5504b91ab1aded9464f0c48cd22e5e420R35) which doesn't look like it was written with data dependencies in mind. Running `./x bench library/core --stage 0 --test-args hash` before and after this change shows the following results: Before: ``` benchmarks: hash::sip::bench_bytes_4 7.20/iter +/- 0.70 hash::sip::bench_bytes_7 9.01/iter +/- 0.35 hash::sip::bench_bytes_8 8.12/iter +/- 0.10 hash::sip::bench_bytes_a_16 10.07/iter +/- 0.44 hash::sip::bench_bytes_b_32 13.46/iter +/- 0.71 hash::sip::bench_bytes_c_128 37.75/iter +/- 0.48 hash::sip::bench_long_str 121.18/iter +/- 3.01 hash::sip::bench_str_of_8_bytes 11.20/iter +/- 0.25 hash::sip::bench_str_over_8_bytes 11.20/iter +/- 0.26 hash::sip::bench_str_under_8_bytes 9.89/iter +/- 0.59 hash::sip::bench_u32 9.57/iter +/- 0.44 hash::sip::bench_u32_keyed 6.97/iter +/- 0.10 hash::sip::bench_u64 8.63/iter +/- 0.07 ``` After: ``` benchmarks: hash::sip::bench_bytes_4 6.64/iter +/- 0.14 hash::sip::bench_bytes_7 8.19/iter +/- 0.07 hash::sip::bench_bytes_8 8.59/iter +/- 0.68 hash::sip::bench_bytes_a_16 9.73/iter +/- 0.49 hash::sip::bench_bytes_b_32 12.70/iter +/- 0.06 hash::sip::bench_bytes_c_128 32.38/iter +/- 0.20 hash::sip::bench_long_str 102.99/iter +/- 0.82 hash::sip::bench_str_of_8_bytes 10.71/iter +/- 0.21 hash::sip::bench_str_over_8_bytes 11.73/iter +/- 0.17 hash::sip::bench_str_under_8_bytes 10.33/iter +/- 0.41 hash::sip::bench_u32 10.41/iter +/- 0.29 hash::sip::bench_u32_keyed 9.50/iter +/- 0.30 hash::sip::bench_u64 8.44/iter +/- 1.09 ``` I ran this on my computer so there's some noise, but you can tell at least `bench_long_str` is significantly faster (~18%). Also, I noticed the same compress function from the library is used in the compiler as well, so I took the liberty of copy-pasting this change to there as well. Thanks `@semisol` for porting SipHash for another project which led me to notice this issue in Rust, and for helping investigate. <3
2024-07-03core: Limit four f16 doctests to x86_64 linuxMartin Nordholts-6/+9
These tests have link errors on many platforms, so limit them to only x86_64 linux for now. There are many other f16 non-doctests, so we don't need to run these particular ones widely.
2024-07-03Rollup merge of #127204 - dimpolo:stabilize_atomic_bool_fetch_not, r=jhprattJacob Pratt-2/+1
Stabilize atomic_bool_fetch_not closes #98485 `@rustbot` modify labels: +T-libs-api
2024-07-03Rollup merge of #123588 - tgross35:stabilize-assert_unchecked, r=dtolnayJacob Pratt-25/+75
Stabilize `hint::assert_unchecked` Make the following API stable, including const: ```rust // core::hint, std::hint pub const unsafe fn assert_unchecked(p: bool); ``` This PR also reworks some of the documentation and adds an example. Tracking issue: https://github.com/rust-lang/rust/issues/119131 FCP: https://github.com/rust-lang/rust/issues/119131#issuecomment-1906394087. The docs update should resolve the remaining concern.
2024-07-02Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methodsNick Fitzgerald-6/+35
Some architectures (i386) do not define a "count leading zeros" instruction, they define a "find first set bit" instruction (`bsf`) whose result is undefined when given zero (ie none of the bits are set). Of this family of bitwise operations, I always forget which of these things is potentially undefined for zero, and I'm also not 100% sure that Rust provides a hard guarantee for the results of these methods when given zero. So I figured there are others who have these same uncertainties, and it would be good to resolve them and answer the question via extending these doc examples/tests. See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info on i386 and `bsf` on zero.
2024-07-02Rollup merge of #127230 - hattizai:patch01, r=saethlinMatthias Krüger-3/+3
chore: remove duplicate words remove duplicate words in comments to improve readability.
2024-07-02chore: remove duplicate wordshattizai-3/+3
2024-07-01Optimize SipHash by reordering compress instructionsmat-5/+6
2024-07-01Rollup merge of #127128 - elomatreb:elomatreb/stabilize-duration_abs_diff, ↵Guillaume Gomez-2/+3
r=joboet Stabilize `duration_abs_diff` Stabilize `duration_abs_diff` following FCP in #117618. Closes #117618.
2024-07-01Rollup merge of #126732 - StackOverflowExcept1on:master, r=m-ou-seGuillaume Gomez-6/+6
Stabilize `PanicInfo::message()` and `PanicMessage` Resolves #66745 This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html). Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker): ```rust #![no_std] #![no_main] extern crate libc; #[no_mangle] extern "C" fn main() -> libc::c_int { panic!("I just panic every time"); } #[panic_handler] fn my_panic(panic_info: &core::panic::PanicInfo) -> ! { use arrayvec::ArrayString; use core::fmt::Write; let message = panic_info.message(); let location = panic_info.location().unwrap(); let mut debug_msg = ArrayString::<1024>::new(); let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'"); if debug_msg.try_push_str("\0").is_ok() { unsafe { libc::puts(debug_msg.as_ptr() as *const _); } } unsafe { libc::exit(libc::EXIT_FAILURE) } } ``` ``` $ cargo +stage1 run --release panicked with 'I just panic every time' at 'src/main.rs:8:5' ``` - [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725 r? libs-api
2024-07-01Stabilize atomic_bool_fetch_notdimi-2/+1
2024-07-01Rollup merge of #127182 - danielhuang:patch-4, r=NilstriebMatthias Krüger-2/+2
Fix error in documentation for IpAddr::to_canonical and Ipv6Addr::to_canonical
2024-06-30Update ip_addr.rsDaniel Huang-2/+2
2024-06-30Print `TypeId` as hex for debuggingTrevor Gross-1/+1
In <https://github.com/rust-lang/rust/pull/127134>, the `Debug` impl for `TypeId` was changed to print a single integer rather than a tuple. Change this again to print as hex for more concise and consistent formatting, as was suggested. Result: TypeId(0x1378bb1c0a0202683eb65e7c11f2e4d7)
2024-06-30Rollup merge of #127069 - Sky9x:fmt-pointer-use-addr, r=NilstriebMatthias Krüger-2/+1
small correction to fmt::Pointer impl ~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~ `expose_provenance` does not require `T: Sized`.
2024-06-30Rollup merge of #126895 - betelgeuse:improve_simd_gather_documentation, ↵Matthias Krüger-3/+0
r=Amanieu Fix simd_gather documentation There is no idx in the function signature.
2024-06-30Rollup merge of #127134 - tgross35:typeid-debug, r=NilstriebMatthias Krüger-1/+12
Print `TypeId` as a `u128` for `Debug` Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is represented as a `(u64, u64)`. This also made the debug implementation a lot larger, which is especially apparent with pretty formatting. Change this to convert the inner value back to a `u128` and then print as a tuple struct to make this less noisy. Current: TypeId { t: (1403077013027291752, 4518903163082958039) } TypeId { t: ( 1403077013027291752, 4518903163082958039, ), } New: TypeId(25882202575019293479932656973818029271) TypeId( 25882202575019293479932656973818029271, )
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 08:54:42 +0000