about summary refs log tree commit diff
path: root/library/core
AgeCommit message (Collapse)AuthorLines
2023-10-18Stabilize `result_option_inspect`Slanterns-13/+4
2023-10-17Disable effects in libcore againOli Scherer-1/+0
2023-10-17Auto merge of #115577 - RalfJung:atomic-load, r=Amanieubors-0/+34
document when atomic loads are guaranteed read-only Based on this [discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Can.20.60Atomic*.3A.3Aload.60.20perform.20a.20write). The values for x86 and x86_64 are complete guesswork on my side, and I have no clue what the values might be for other architectures. I hope we can get the right people to chime in to gather the required information. :) I'll update Miri to respect these rules once we have more data.
2023-10-17remove 128bit atomics, they are anyway not exposed on those targetsRalf Jung-2/+1
2023-10-16Make `rustc_onunimplemented` export path agnosticNilstrieb-60/+30
This makes it so that all the matchers that match against paths use the definition path instead of the export path. This removes all duplication around `std`/`alloc`/`core`. This is not necessarily optimal because we now depend on internal implementation details like `core::ops::control_flow::ControlFlow`, which is not very nice and probably not acceptable for a stable `on_unimplemented`. An alternative would be to just string-replace normalize away `alloc`/`core` to `std` as a special case, keeping the export paths but making it so that we're still fully standard library flavor agnostic.
2023-10-16use target-arch based tableRalf Jung-5/+4
2023-10-16Add `#[track_caller]` to `Option::unwrap_or_else`DaniPopes-0/+1
2023-10-16Rollup merge of #115955 - tgross35:ip-to-canonical, r=dtolnayMatthias Krüger-10/+13
Stabilize `{IpAddr, Ipv6Addr}::to_canonical` Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: ```rust impl IpAddr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } ``` These stabilize a subset of the following tracking issues: - https://github.com/rust-lang/rust/issues/27709 - https://github.com/rust-lang/rust/issues/76205 Stabilization of all methods under the `ip` gate was attempted once at https://github.com/rust-lang/rust/pull/66584 then again at https://github.com/rust-lang/rust/pull/76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward. I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in https://github.com/rust-lang/rust/pull/87708 cc implementor ``@the8472`` r? libs-api ``@rustbot`` label +T-libs-api +needs-fcp
2023-10-15Auto merge of #113747 - clarfonthey:ip_bitops, r=dtolnaybors-0/+131
impl Not, Bit{And,Or}{,Assign} for IP addresses ACP: rust-lang/libs-team#235 Note: since these are insta-stable, these require an FCP. Implements, where `N` is either `4` or `6`: ```rust impl Not for IpvNAddr impl Not for &IpvNAddr impl BitAnd<IpvNAddr> for IpvNAddr impl BitAnd<&IpvNAddr> for IpvNAddr impl BitAnd<IpvNAddr> for &IpvNAddr impl BitAnd<&IpvNAddr> for &IpvNAddr impl BitAndAssign<IpvNAddr> for IpvNAddr impl BitAndAssign<&IpvNAddr> for IpvNAddr impl BitOr<IpvNAddr> for IpvNAddr impl BitOr<&IpvNAddr> for IpvNAddr impl BitOr<IpvNAddr> for &IpvNAddr impl BitOr<&IpvNAddr> for &IpvNAddr impl BitOrAssign<IpvNAddr> for IpvNAddr impl BitOrAssign<&IpvNAddr> for IpvNAddr ```
2023-10-15Rollup merge of #116760 - Nilstrieb:triviality, r=oli-obkMatthias Krüger-1/+1
Remove trivial cast in `guaranteed_eq` I found this while accidentally breaking trivial casts in another branch. r? oli-obk
2023-10-15Auto merge of #110729 - ColinFinck:decode-utf16-fused-iterator, r=dtolnaybors-0/+4
Implement FusedIterator for DecodeUtf16 when the inner iterator does I have just implemented an iterator that wraps `DecodeUtf16` and wanted to implement `FusedIterator` for my iterator when I noticed that `DecodeUtf16` currently doesn't implement `FusedIterator` at all. A quick look at the code of `DecodeUtf16` revealed that `DecodeUtf16::next` only returns `None` when its inner iterator returns `None`: https://github.com/rust-lang/rust/blob/3462f79e94f466a56ddaccfcdd3a3d44dd1dda9f/library/core/src/char/decode.rs#L45 As a result, we can implement `FusedIterator` for `DecodeUtf16` when the inner iterator does. I'm following the example of #96397 here and consider this change minor and non-controversial, which is why I haven't added an RFC. I have also added the required feature name (`"decode_utf16_fused_iterator"`), however without adding a chapter to the Rust Unstable book (same as #96397).
2023-10-15acquire loads can be done as relaxed load; acquire fenceRalf Jung-0/+3
2023-10-15only guarantee for Relaxed; add ptr-size fallbackRalf Jung-18/+15
2023-10-15wordingRalf Jung-9/+13
2023-10-15define 'read-only memory'Ralf Jung-1/+8
2023-10-15add general powerpc64le boundRalf Jung-7/+8
(some powerpc64le targets can guarantee more, but for now it doesn't seem worth separating by OS/vendor)
2023-10-15add ARM and RISC-V valuesRalf Jung-3/+7
2023-10-15document when atomic loads are guaranteed read-onlyRalf Jung-0/+20
2023-10-15Add tests for `SocketAddrV6` ordering with scope_id and flowinfoMaybe Waffle-0/+11
2023-10-15Remove trivial cast in `guaranteed_eq`Nilstrieb-1/+1
I found this while accidentally breaking trivial casts in another branch.
2023-10-15Rollup merge of #116594 - tae-soo-kim:convert-tryfrom-doc, r=scottmcmMatthias Krüger-6/+5
Fix `std::convert::TryFrom` doc Original text: > truncating the [i64](https://doc.rust-lang.org/std/primitive.i64.html) to an [i32](https://doc.rust-lang.org/std/primitive.i32.html) (essentially giving the [i64](https://doc.rust-lang.org/std/primitive.i64.html)’s value modulo [i32::MAX](https://doc.rust-lang.org/std/primitive.i32.html#associatedconstant.MAX)) This can't be true, because `i32::MAX` is an odd number. The correct value seems `(i32::MAX + 1) * 2`, but this is complicated and distracting, and I suggest removing the parentheses entirely.
2023-10-15Auto merge of #115515 - the8472:zip-for-arrays, r=scottmcmbors-2/+121
optimize zipping over array iterators Fixes #115339 (somewhat) the new assembly: ```asm zip_arrays: .cfi_startproc vmovups (%rdx), %ymm0 leaq 32(%rsi), %rcx vxorps %xmm1, %xmm1, %xmm1 vmovups %xmm1, -24(%rsp) movq $0, -8(%rsp) movq %rsi, -88(%rsp) movq %rdi, %rax movq %rcx, -80(%rsp) vmovups %ymm0, -72(%rsp) movq $0, -40(%rsp) movq $32, -32(%rsp) movq -24(%rsp), %rcx vmovups (%rsi,%rcx), %ymm0 vorps -72(%rsp,%rcx), %ymm0, %ymm0 vmovups %ymm0, (%rsi,%rcx) vmovups (%rsi), %ymm0 vmovups %ymm0, (%rdi) vzeroupper retq ``` This is still longer than the slice version given in the issue but at least it eliminates the terrible `vpextrb`/`orb` chain. I guess this is due to excessive memcpys again (haven't looked at the llvmir)? The `TrustedLen` specialization is a drive-by change since I had to do something for the default impl anyway to be able to specialize the `TrustedRandomAccessNoCoerce` impl.
2023-10-14Rollup merge of #116540 - daxpedda:once-cell-lock-try-insert, r=Mark-SimulacrumGuillaume Gomez-9/+37
Implement `OnceCell/Lock::try_insert()` I took inspiration from [`once_cell`](https://crates.io/crates/once_cell): - [`once_cell::unsync::OnceCell::try_insert()`](https://github.com/matklad/once_cell/blob/874f9373abd7feaf923a3b3c34bfb3383529c671/src/lib.rs#L551-L563) - [`once_cell::sync::OnceCell::try_insert()`](https://github.com/matklad/once_cell/blob/874f9373abd7feaf923a3b3c34bfb3383529c671/src/lib.rs#L1080-L1087) I tried to change as little code as possible in the first commit and applied some obvious optimizations in the second one. ACP: https://github.com/rust-lang/libs-team/issues/276 Tracking issue: #116693
2023-10-14Rollup merge of #115653 - joshlf:patch-9, r=dtolnayMatthias Krüger-0/+2
Guarantee that Layout::align returns a non-zero power of two
2023-10-14Auto merge of #116407 - Mark-Simulacrum:bootstrap-bump, r=onur-ozkanbors-125/+115
Bump bootstrap compiler to just-released beta https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
2023-10-14Guarantee representation of None in NPOJoshua Liebow-Feeser-9/+15
2023-10-14Auto merge of #115719 - tgross35:atomic-from-ptr, r=dtolnaybors-16/+45
Stabilize `atomic_from_ptr` This stabilizes `atomic_from_ptr` and moves the const gate to `const_atomic_from_ptr`. Const stability is blocked on `const_mut_refs`. Tracking issue: #108652 Newly stable API: ```rust // core::atomic impl AtomicBool { pub unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a AtomicBool; } impl<T> AtomicPtr<T> { pub unsafe fn from_ptr<'a>(ptr: *mut *mut T) -> &'a AtomicPtr<T>; } impl AtomicU8 { pub unsafe fn from_ptr<'a>(ptr: *mut u8) -> &'a AtomicU8; } impl AtomicU16 { pub unsafe fn from_ptr<'a>(ptr: *mut u16) -> &'a AtomicU16; } impl AtomicU32 { pub unsafe fn from_ptr<'a>(ptr: *mut u32) -> &'a AtomicU32; } impl AtomicU64 { pub unsafe fn from_ptr<'a>(ptr: *mut u64) -> &'a AtomicU64; } impl AtomicUsize { pub unsafe fn from_ptr<'a>(ptr: *mut usize) -> &'a AtomicUsize; } impl AtomicI8 { pub unsafe fn from_ptr<'a>(ptr: *mut i8) -> &'a AtomicI8; } impl AtomicI16 { pub unsafe fn from_ptr<'a>(ptr: *mut i16) -> &'a AtomicI16; } impl AtomicI32 { pub unsafe fn from_ptr<'a>(ptr: *mut i32) -> &'a AtomicI32; } impl AtomicI64 { pub unsafe fn from_ptr<'a>(ptr: *mut i64) -> &'a AtomicI64; } impl AtomicIsize { pub unsafe fn from_ptr<'a>(ptr: *mut isize) -> &'a AtomicIsize; } ```
2023-10-14Derive `Ord`, `PartialOrd` and `Hash` for `SocketAddr*`Maybe Waffle-49/+2
...instead of hand rolling impls, since 1. It's nicer 2. It fixes a buggy `Ord` impl of `SocketAddrV6`, which ignored half of the fields
2023-10-13Stabilize 'atomic_from_ptr', move const gate to 'const_atomic_from_ptr'Trevor Gross-9/+9
2023-10-13Correct documentation for `atomic_from_ptr`Trevor Gross-7/+36
* Remove duplicate alignment note that mentioned `AtomicBool` with other types * Update safety requirements about when non-atomic operations are allowed
2023-10-13Auto merge of #116233 - ↵bors-2/+4
DaniPopes:stabilize-const_maybe_uninit_assume_init_read, r=dtolnay Stabilize `const_maybe_uninit_assume_init_read` AFAICT the only reason this was not included in the `maybe_uninit_extra` stabilization was because `ptr::read` was unstable (https://github.com/rust-lang/rust/pull/92768#issuecomment-1011101383), which has since been stabilized in 1.71. Needs a separate FCP from the [original `maybe_uninit_extra` one](https://github.com/rust-lang/rust/issues/63567#issuecomment-964428807). Tracking issue: #63567
2023-10-13Update primitive_docs.rsJoshua Liebow-Feeser-3/+2
2023-10-13Update library/core/src/primitive_docs.rsJoshua Liebow-Feeser-1/+5
Co-authored-by: Ralf Jung <post@ralfj.de>
2023-10-13Add some optimizationsdaxpedda-5/+3
2023-10-13Implement `OnceCell/Lock::try_insert()`daxpedda-5/+35
2023-10-13Clean up unchecked_math, separate out unchecked_shiftsltdk-19/+45
2023-10-13Remove Not for IpAddrltdk-23/+0
2023-10-13impl Not, Bit{And,Or,Xor}{,Assign} for IP addressesltdk-0/+154
2023-10-12Update primitive_docs.rsJoshua Liebow-Feeser-1/+0
2023-10-12Update library/core/src/alloc/layout.rsJoshua Liebow-Feeser-1/+1
Co-authored-by: David Tolnay <dtolnay@gmail.com>
2023-10-12References refer to allocated objectsJoshua Liebow-Feeser-0/+12
2023-10-11Auto merge of #112818 - Benjamin-L:add-slice_split_once, r=cuviperbors-0/+77
Implement `slice::split_once` and `slice::rsplit_once` Feature gate is `slice_split_once` and tracking issue is #112811. These are equivalents to the existing `str::split_once` and `str::rsplit_once` methods.
2023-10-10Update mod.rstae-soo-kim-6/+5
2023-10-08rustdoc: remove rust logo from non-Rust cratesMichael Howell-0/+1
2023-10-08Bump to latest betaMark Rousskov-36/+26
2023-10-07Auto merge of #100806 - timvermeulen:split_inclusive_double_ended_bound, ↵bors-1/+1
r=dtolnay Fix generic bound of `str::SplitInclusive`'s `DoubleEndedIterator` impl `str::SplitInclusive`'s `DoubleEndedIterator` implementation currently uses a `ReverseSearcher` bound for the corresponding searcher. A `DoubleEndedSearcher` bound should have been used instead. `DoubleEndedIterator` requires that repeated `next_back` calls produce the same items as repeated `next` calls, in opposite order. `ReverseSearcher` lets you search starting from the back of a string, but it makes no guarantees about how its matches correspond to the matches found by a forward search. `DoubleEndedSearcher` is a subtrait of `ReverseSearcher` and does require that the same matches are found in both directions. This bug fix is a breaking change. Calling `next_back` on `"a+++b".split_inclusive("++")` is currently accepted with repeated calls producing `"b"` and `"a+++"`, while forward iteration yields `"a++"` and `"+b"`. Also see https://github.com/rust-lang/rust/issues/100756#issuecomment-1221307166 for more details. I believe that this is the only iterator that uses this bound incorrectly — other related iterators such as `str::Split` do have a `DoubleEndedSearcher` bound for their `DoubleEndedIterator` implementation. And `slice::SplitInclusive` doesn't face this problem at all because it doesn't use patterns, only a predicate. cc `@SkiFire13`
2023-10-07Expose tests for {f32,f64}.total_cmp in docs, along with commentEd Swartz-6/+22
Uncomment the assert! line and account and document that the sign of NaN is not positive, necessarily.
2023-10-06Rollup merge of #116481 - scottmcm:tweak-combinators, r=cuviperMatthias Krüger-4/+4
Reuse existing `Some`s in `Option::(x)or` LLVM still has trouble re-using discriminants sometimes when rebuilding a two-variant enum, so when we have the correct variant already built, just use it. That's shorter in the Rust code, as well as simpler in MIR and the optimized LLVM, so might as well: <https://rust.godbolt.org/z/KhdE8eToW> Thanks to `@veber-alex` for pointing out this opportunity in https://github.com/rust-lang/rust/issues/101210#issuecomment-1732470941
2023-10-06Rollup merge of #114564 - scottmcm:when-to-from, r=dtolnayMatthias Krüger-0/+40
Attempt to describe the intent behind the `From` trait further Inspired by the <https://internals.rust-lang.org/t/allow-use-as-and-try-as-for-from-and-tryfrom-traits/19240/26?u=scottmcm> thread. `@rustbot` label +T-libs-api
2023-10-06optimize zipping over array iteratorsThe 8472-2/+121
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 03:42:50 +0000