about summary refs log tree commit diff
path: root/library/core
AgeCommit message (Collapse)AuthorLines
2025-09-27Remove `cfg(bootstrap)` for `doc_cfg` feature following #141925Guillaume Gomez-49/+21
2025-09-27Remove `doc_cfg_hide` featureGuillaume Gomez-1/+1
2025-09-27Implement RFC 3631Guillaume Gomez-21/+48
2025-09-26Update CURRENT_RUSTC_VERSION post-bumpMark Rousskov-93/+93
2025-09-25Auto merge of #147037 - matthiaskrgr:rollup-xtgqzuu, r=matthiaskrgrbors-0/+12
Rollup of 8 pull requests Successful merges: - rust-lang/rust#116882 (rustdoc: hide `#[repr]` if it isn't part of the public ABI) - rust-lang/rust#135771 ([rustdoc] Add support for associated items in "jump to def" feature) - rust-lang/rust#141032 (avoid violating `slice::from_raw_parts` safety contract in `Vec::extract_if`) - rust-lang/rust#142401 (Add proper name mangling for pattern types) - rust-lang/rust#146293 (feat: non-panicking `Vec::try_remove`) - rust-lang/rust#146859 (BTreeMap: Don't leak allocators when initializing nodes) - rust-lang/rust#146924 (Add doc for `NonZero*` const creation) - rust-lang/rust#146933 (Make `render_example_with_highlighting` return an `impl fmt::Display`) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-25Rollup merge of #146924 - cptpiepmatz:doc-nonzero-const-creation, r=joboetMatthias Krüger-0/+12
Add doc for `NonZero*` const creation I ran into trouble using `NonZero*` values because I didn’t see any clear way to create them at compile time. At first I ended up using `NonZero*::new_unchecked` a lot, until I realized that `Option::unwrap` and `Option::expect` are `const` and can be used in a `const` context. With that, you can create non-zero values at compile time safely, without touching `unsafe`. This wasn’t obvious to me and my peers who’ve been using Rust for a while, so I thought adding a note to the docs would make it easier for others to discover. If this should be worded differently or placed in another location, we can do that. I just want to make this more obvious.
2025-09-25add doc for `NonZero*` const creationTim 'Piepmatz' Hesse-0/+12
2025-09-25Auto merge of #147019 - Zalathar:rollup-boxzbmo, r=Zalatharbors-12/+16
Rollup of 14 pull requests Successful merges: - rust-lang/rust#145067 (RawVecInner: add missing `unsafe` to unsafe fns) - rust-lang/rust#145277 (Do not materialise X in [X; 0] when X is unsizing a const) - rust-lang/rust#145973 (Add `std` support for `armv7a-vex-v5`) - rust-lang/rust#146667 (Add an attribute to check the number of lanes in a SIMD vector after monomorphization) - rust-lang/rust#146735 (unstably constify float mul_add methods) - rust-lang/rust#146737 (f16_f128: enable some more tests in Miri) - rust-lang/rust#146766 (Add attributes for #[global_allocator] functions) - rust-lang/rust#146905 (llvm: update remarks support on LLVM 22) - rust-lang/rust#146982 (Remove erroneous normalization step in `tests/run-make/linker-warning`) - rust-lang/rust#147005 (Small string formatting cleanup) - rust-lang/rust#147007 (Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`) - rust-lang/rust#147008 (bootstrap.py: Respect build.jobs while building bootstrap tool) - rust-lang/rust#147013 (rustdoc: Fix documentation for `--doctest-build-arg`) - rust-lang/rust#147015 (Use `LLVMDisposeTargetMachine`) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-25Rollup merge of #146735 - Qelxiros:const_mul_add, r=tgross35,RalfJungStuart Cook-12/+16
unstably constify float mul_add methods Tracking issue: rust-lang/rust#146724 r? `@tgross35`
2025-09-25Auto merge of #147003 - matthiaskrgr:rollup-b5z9uiz, r=matthiaskrgrbors-4/+8
Rollup of 7 pull requests Successful merges: - rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks) - rust-lang/rust#146679 (Clarify Display for error should not include source) - rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause) - rust-lang/rust#146894 (Improve derive suggestion of const param) - rust-lang/rust#146950 (core: simplify `CStr::default()`) - rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String) - rust-lang/rust#146971 (fix ICE in writeback due to bound regions) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-24Rollup merge of #146950 - joboet:cstr_default, r=tgross35Matthias Krüger-3/+1
core: simplify `CStr::default()` Just use a `CStr`-literal...
2025-09-24unstably constify float mul_add methodsJeremy Smart-12/+16
Co-authored-by: Ralf Jung <post@ralfj.de>
2025-09-24Clarify Display for error should not include sourceStepan Koltsov-1/+7
2025-09-24Rollup merge of #146915 - clarfonthey:safe-intrinsics-2, r=RalfJungMatthias Krüger-20/+14
Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to rust-lang/rust#146683. r? ```@RalfJung``` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
2025-09-24core: simplify `CStr::default()`joboet-3/+1
Just use a `CStr`-literal...
2025-09-23Make missed precondition-free float intrinsics safeltdk-20/+14
2025-09-23Rollup merge of #146818 - npmccallum:total_cmp, r=fee1-deadMatthias Krüger-4/+8
constify {float}::total_cmp()
2025-09-23Rollup merge of #146632 - ctz:jbp-adaptor-spelling, r=petrochenkovMatthias Krüger-1/+1
Fix uses of "adaptor" These docs are in en_US, so "adapter" is the correct spelling (and indeed used in the next line.) A second commit comes along for the ride to fix other instances in non-rustdoc comments.
2025-09-23Auto merge of #146317 - saethlin:panic=immediate-abort, r=nnethercotebors-59/+62
Add panic=immediate-abort MCP: https://github.com/rust-lang/compiler-team/issues/909 This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts. In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`. The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large. `-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing. The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature. To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it. I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
2025-09-22Auto merge of #146683 - clarfonthey:safe-intrinsics, r=RalfJung,Amanieubors-125/+97
Mark float intrinsics with no preconditions as safe Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit. All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls. --- Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
2025-09-22constify {float}::total_cmp()Nathaniel McCallum-4/+8
2025-09-22assert_unsafe_precondition: fix some incorrect check_language_ubRalf Jung-9/+10
2025-09-21Mark float intrinsics with no preconditions as safeltdk-125/+97
2025-09-21Change the cfg to a dashBen Kimock-54/+54
2025-09-21Add panic=immediate-abortBen Kimock-59/+62
2025-09-21Rollup merge of #145664 - Darksonn:stab-file-with-nul, r=Mark-SimulacrumStuart Cook-1/+2
Stabilize `std::panic::Location::file_as_c_str` Closes: rust-lang/rust#141727 Nominating this for T-lang as per ```@traviscross``` https://github.com/rust-lang/rust/issues/141727#issuecomment-3201318429
2025-09-19Fix std build for xtensaThalia Archibald-0/+1
2025-09-19Rollup merge of #146690 - npmccallum:convo, r=tgross35Matthias Krüger-1/+3
add `[const] PartialEq` bound to `PartialOrd` This change is included for discussion purposes. The PartialOrd bound on PartialEq is not strictly necessary. It is, rather, logical: anything which is orderable should by definition have equality. Is the same true for constness? Should every type which is const orderable also have const equality?
2025-09-18Specialize `Iterator::eq[_by]` for `TrustedLen` iteratorsYotam Ofek-4/+48
2025-09-17add `[const] PartialEq` bound to `PartialOrd`Nathaniel McCallum-1/+3
This change is included for discussion purposes. The PartialOrd bound on PartialEq is not strictly necessary. It is, rather, logical: anything which is orderable should by definition have equality. Is the same true for constness? Should every type which is const orderable also have const equality?
2025-09-17Rollup merge of #146564 - cjgillot:mir-nolen, r=scottmcmStuart Cook-2/+9
Remove Rvalue::Len again. Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`. r? ``@scottmcm``
2025-09-17Rollup merge of #146410 - hkBst:repeat-1, r=jhprattStuart Cook-3/+4
Iterator repeat: no infinite loop for `last` and `count` This removes two cases of infinite looping from [`Repeat`](https://doc.rust-lang.org/nightly/std/iter/struct.Repeat.html): - [`last`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.last): By viewing the iterator as returning None after [omega](https://en.wikipedia.org/wiki/Ordinal_number) calls to `next`, this method can simply return the repeated element. - [`count`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.count): From its docs: """The method does no guarding against overflows, so counting elements of an iterator with more than [usize::MAX](https://doc.rust-lang.org/nightly/std/primitive.usize.html#associatedconstant.MAX) elements either produces the wrong result or panics. If overflow checks are enabled, a panic is guaranteed.""", so a panic'ing impl is allowed by the docs, and is more honest than an infinite loop.
2025-09-17Rollup merge of #145660 - jbatez:darwin_objc, r=jdonszelmann,madsmtm,tmandryStuart Cook-0/+157
initial implementation of the darwin_objc unstable feature Tracking issue: https://github.com/rust-lang/rust/issues/145496 This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time. r? ```@tmandry``` try-job: `*apple*` try-job: `x86_64-gnu-nopt`
2025-09-16Update docs.Camille Gillot-1/+2
2025-09-16Remove Rvalue::Len.Camille Gillot-1/+7
2025-09-16Fix other uses of "adaptor"Joe Birr-Pixton-1/+1
2025-09-16Iterator repeat: no infinite loop for `last` and `count`Marijn Schouten-3/+4
2025-09-16Auto merge of #146614 - Zalathar:rollup-hcxvdi1, r=Zalatharbors-45/+13
Rollup of 9 pull requests Successful merges: - rust-lang/rust#145095 (Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`) - rust-lang/rust#145960 (Split `FnCtxt::report_args_error` into subfunctions) - rust-lang/rust#146402 (interpret: fix overlapping aggregate initialization) - rust-lang/rust#146466 (llvm-wrapper: other cleanup) - rust-lang/rust#146574 (compiletest: Enable new-output-capture by default) - rust-lang/rust#146599 (replace some `#[const_trait]` with `const trait`) - rust-lang/rust#146601 (compiletest: Make `./x test --test-args ...` work again) - rust-lang/rust#146608 (improve internal bootstrap docs) - rust-lang/rust#146609 (bootstrap: lower verbosity of cargo to one less than bootstrap's) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-16Rollup merge of #146599 - npmccallum:cleanup, r=fmeaseStuart Cook-6/+3
replace some `#[const_trait]` with `const trait`
2025-09-16Rollup merge of #145095 - tiif:unstable_const_param, r=BoxyUwUStuart Cook-39/+10
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_` Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait. r? `@BoxyUwU`
2025-09-15Rollup merge of #146533 - Zalathar:array-default, r=compiler-errorsMatthias Krüger-0/+5
Note some previous attempts to change the Default impl for `[T; 0]` Recently, rust-lang/rust#145457 experimented with changing the Default impl for `[T; 0]`. Subsequently, rust-lang/rust#146531 also aimed to perform a similar experiment. It seems like a good idea to add some links to the relevant source code, so that the historical context of this tricky topic is easier to find.
2025-09-15replace some `#[const_trait]` with `const trait`Nathaniel McCallum-6/+3
2025-09-15Remove UnsizedConstParamTy trait and make it into an unstable impltiif-39/+10
2025-09-15Rollup merge of #146284 - Kivooeo:blazing-fast-division-bignum, ↵Matthias Krüger-37/+0
r=Mark-Simulacrum Remove `div_rem` from `core::num::bignum` This fixes very old fixme that sounds like this ``` Stupid slow base-2 long division taken from https://en.wikipedia.org/wiki/Division_algorithm FIXME use a greater base ($ty) for the long division. ``` By deleting this method since it was never used
2025-09-14Note some previous attempts to change the Default impl for `[T; 0]`Zalathar-0/+5
2025-09-13initial implementation of the darwin_objc unstable featureJo Bates-0/+157
2025-09-13Rollup merge of #146521 - folkertdev:document-va-arg-safe, r=workingjubileeJacob Pratt-6/+23
document `core::ffi::VaArgSafe` tracking issue: https://github.com/rust-lang/rust/issues/44930 A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait. Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types. This PR also adds some various other tests for edge cases of c-variadic: - the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions. - naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported - guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it. r? `@workingjubilee`
2025-09-13c-variadic: document `core::ffi::VaArgSafe`Folkert de Vries-6/+23
and document `VaList::arg`.
2025-09-12Constify Eq, Ord, PartialOrdEvgenii Zheltonozhskii-103/+216
2025-09-11Rollup merge of #142315 - lolbinarycat:core-dedup-ptr-docs-139190-pt3, ↵Stuart Cook-134/+111
r=workingjubilee core::ptr: deduplicate docs for as_ref, addr, and as_uninit_ref also add INFO.md file explaining the purpose of the ptr/docs dir, and give some pointers (heh) to future maintainers. follow up to rust-lang/rust#142101 part of rust-lang/rust#139190 r? `@workingjubilee`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-09 07:35:59 +0000