about summary refs log tree commit diff
path: root/library/core/src
AgeCommit message (Collapse)AuthorLines
2023-10-24Rollup merge of #117081 - GoodDaisy:master, r=wesleywiserMatthias Krüger-1/+1
fix typos in comments
2023-10-24Auto merge of #116773 - dtolnay:validatestable, r=compiler-errorsbors-1/+1
Validate `feature` and `since` values inside `#[stable(…)]` Previously the string passed to `#[unstable(feature = "...")]` would be validated as an identifier, but not `#[stable(feature = "...")]`. In the standard library there were `stable` attributes containing the empty string, and kebab-case string, neither of which should be allowed. Pre-existing validation of `unstable`: ```rust // src/lib.rs #![allow(internal_features)] #![feature(staged_api)] #![unstable(feature = "kebab-case", issue = "none")] #[unstable(feature = "kebab-case", issue = "none")] pub struct Struct; ``` ```console error[E0546]: 'feature' is not an identifier --> src/lib.rs:5:1 | 5 | #![unstable(feature = "kebab-case", issue = "none")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` For an `unstable` attribute, the need for an identifier is obvious because the downstream code needs to write a `#![feature(...)]` attribute containing that identifier. `#![feature(kebab-case)]` is not valid syntax and `#![feature(kebab_case)]` would not work if that is not the name of the feature. Having a valid identifier even in `stable` is less essential but still useful because it allows for informative diagnostic about the stabilization of a feature. Compare: ```rust // src/lib.rs #![allow(internal_features)] #![feature(staged_api)] #![stable(feature = "kebab-case", since = "1.0.0")] #[stable(feature = "kebab-case", since = "1.0.0")] pub struct Struct; ``` ```rust // src/main.rs #![feature(kebab_case)] use repro::Struct; fn main() {} ``` ```console error[E0635]: unknown feature `kebab_case` --> src/main.rs:3:12 | 3 | #![feature(kebab_case)] | ^^^^^^^^^^ ``` vs the situation if we correctly use `feature = "snake_case"` and `#![feature(snake_case)]`, as enforced by this PR: ```console warning: the feature `snake_case` has been stable since 1.0.0 and no longer requires an attribute to enable --> src/main.rs:3:12 | 3 | #![feature(snake_case)] | ^^^^^^^^^^ | = note: `#[warn(stable_features)]` on by default ```
2023-10-23Remove FnPtr hack from trait_ref_is_knowableMichael Goulet-0/+1
2023-10-23Fix invalid stability attribute features in standard libraryDavid Tolnay-1/+1
2023-10-23fix typos in commentsGoodDaisy-1/+1
2023-10-22use visibility to check unused imports and delete some stmtsbohan-0/+1
2023-10-21Clarify UB in `get_unchecked(_mut)`Scott McMurray-0/+10
2023-10-22Add #[inline] to some recalcitrant ops::range methodsBen Kimock-0/+7
2023-10-20Fix stage0 core testsOli Scherer-3/+8
2023-10-20s/generator/coroutine/Oli Scherer-71/+73
2023-10-20s/Generator/Coroutine/Oli Scherer-37/+37
2023-10-20document that the null pointer has the 0 addressRalf Jung-0/+10
2023-10-20Fix typo in atomic docsltdk-1/+1
2023-10-19Rollup merge of #116795 - DaniPopes:track-caller-option, r=cuviperLeón Orell Valerian Liehr-0/+1
Add `#[track_caller]` to `Option::unwrap_or_else` Same as #116317 but for `Option`. Closes #115302
2023-10-18Guarantee that `char` has the same size and alignment as `u32`Joshua Liebow-Feeser-1/+4
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-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-1/+116
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-1/+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