| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 9 pull requests
Successful merges:
- #132156 (When encountering unexpected closure return type, point at return type/expression)
- #133429 (Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle)
- #136281 (`rustc_hir_analysis` cleanups)
- #136297 (Fix a typo in profile-guided-optimization.md)
- #136300 (atomic: extend compare_and_swap migration docs)
- #136310 (normalize `*.long-type.txt` paths for compare-mode tests)
- #136312 (Disable `overflow_delimited_expr` in edition 2024)
- #136313 (Filter out RPITITs when suggesting unconstrained assoc type on too many generics)
- #136323 (Fix a typo in conventions.md)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
atomic: extend compare_and_swap migration docs
Fixes https://github.com/rust-lang/rust/issues/80486
|
|
float::min/max: mention the non-determinism around signed 0
Turns out this can actually produce different results on different machines [in practice](https://github.com/rust-lang/rust/issues/83984#issuecomment-2623859230); that seems worth documenting. I assume LLVM will happily const-fold these operations so so there could be different results for the same input even on the same machine, depending on whether things get const-folded or not.
`@nikic` I remember there was an LLVM soundness fix regarding scalar evolution for loops that had to recognize certain operations as non-deterministic... it seems to me that pass would also have to avoid predicting the result of `llvm.{min,max}num`, for the same reason?
r? `@tgross35`
Cc `@rust-lang/libs-api`
If this lands we should also make Miri non-deterministic here.
Fixes https://github.com/rust-lang/rust/issues/83984
|
|
Stabilize `const_black_box`
This has been unstably const since #92226, but a tracking issue was never created. Per [discussion on Zulip][zulip], there should not be any blockers to making this const-stable. The function does not provide any functionality at compile time but does allow code reuse between const- and non-const functions, so stabilize it here.
[zulip]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
|
|
`<` seems to be the "lucky one" for llvm
|
|
for RFC 3550, tracking issue #123741
|
|
- add tests for `a == b` where missing
- try to make all the tests more similar
- try to use more illustrative test values
|
|
Remove minor future footgun in `impl Debug for MaybeUninit`
No longer breaks if `MaybeUninit` moves modules (technically it could break if `MaybeUninit` were renamed but realistically that will never happen)
Debug impl originally added in #133282
|
|
Add `AsyncFn*` to `core` prelude
In https://github.com/rust-lang/rust/pull/132611 these got added to the `std` prelude only, which looks like an oversight.
r? libs-api
cc `@compiler-errors`
|
|
Implement `int_from_ascii` (#134821)
Provides unstable `T::from_ascii()` and `T::from_ascii_radix()` for integer types `T`, as drafted in tracking issue #134821.
To deduplicate documentation without additional macros, implementations of `isize` and `usize` no longer delegate to equivalent integer types. After #132870 they are inlined anyway.
|
|
|
|
|
|
Cleanup docs for Allocator
This is an attempt to remove ungrammatical constructions and clean up the prose. I've sometimes had to try hard to understand what was being stated, so it is possible that I've misunderstood the original meaning. In particular, I did not see a difference between:
- the borrow-checker lifetime of the allocator type itself.
- as long as at least one of the allocator instance and all of its clones has not been dropped.
|
|
optimize slice::ptr_rotate for small rotates
r? `@scottmcm`
This swaps the positions and numberings of algorithms 1 and 2 in `slice::ptr_rotate`, and pulls the entire outer loop into algorithm 3 since it was redundant for the first two. Effectively, `ptr_rotate` now always does the `memcpy`+`memmove`+`memcpy` sequence if the shifts fit into the stack buffer.
With this change, an `IndexMap`-style `move_index` function is optimized correctly.
Assembly comparisons:
- `move_index`, before: https://godbolt.org/z/Kr616KnYM
- `move_index`, after: https://godbolt.org/z/1aoov6j8h
- the code from `#89714`, before: https://godbolt.org/z/Y4zaPxEG6
- the code from `#89714`, after: https://godbolt.org/z/1dPx83axc
related to #89714
some relevant discussion in https://internals.rust-lang.org/t/idea-shift-move-to-efficiently-move-elements-in-a-vec/22184
Behavior tests pass locally. I can't get any consistent microbenchmark results on my machine, but the assembly diffs look promising.
|
|
No longer breaks if `MaybeUninit` moves modules (technically it could break if `MaybeUninit` were renamed but realistically that will never happen)
|
|
|
|
|
|
inlining
|
|
Fixes #136103.
Based on the analysis by @jonathan-gruber-jg and @orlp.
|
|
[cfg_match] Document the use of expressions.
cc #115585
Adds documentation to this new feature introduced in #133720.
|
|
Rollup of 9 pull requests
Successful merges:
- #135869 (Make docs for AtomicUsize::from_mut platform-independent)
- #135892 (-Znext-solver: "normalize" signature before checking it mentions self in `deduce_closure_signature`)
- #136055 (Implement MIR const trait stability checks)
- #136066 (Pass spans to `perform_locally_in_new_solver`)
- #136071 ([Clippy] Add vec_reserve & vecdeque_reserve diagnostic items)
- #136124 (Arbitrary self types v2: explain test.)
- #136149 (Flip the `rustc-rayon`/`indexmap` dependency order)
- #136173 (Update comments and sort target_arch in c_char_definition)
- #136178 (Update username in build helper example)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update comments and sort target_arch in c_char_definition
Follow-up to https://github.com/rust-lang/rust/pull/132975.
- Clang's wrong default on MSP430 has been fixed in https://github.com/llvm/llvm-project/pull/115964, and will be included in LLVM 20, which will be used soon.
- Add a reference on Xtensa's default (from https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240).
- Fix link for Windows's default.
- Add a link to the discussion on L4Re (https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240)
- Sort `target_arch`. (now match with `target_arch`s in comments)
r? `@tgross35`
|
|
Make docs for AtomicUsize::from_mut platform-independent
fixes #133342
|
|
* Renames the methods:
* `get_many_mut` -> `get_disjoint_mut`
* `get_many_unchecked_mut` -> `get_disjoint_unchecked_mut`
* Does not rename the feature flag: `get_many_mut`
* Marks the feature as stable
* Renames some helper stuff:
* `GetManyMutError` -> `GetDisjointMutError`
* `GetManyMutIndex` -> `GetDisjointMutIndex`
* `get_many_mut_helpers` -> `get_disjoint_mut_helpers`
* `get_many_check_valid` -> `get_disjoint_check_valid`
This only touches slice methods.
HashMap's methods and feature gates are not renamed here
(nor are they stabilized).
|
|
Document purpose of closure in from_fn.rs more clearly
partial fix for #135087 together with https://github.com/rust-lang/rust/pull/135895
|
|
Implement `AtomicT::update` & `AtomicT::try_update`
ACP accepted in https://github.com/rust-lang/libs-team/issues/490
``@rustbot`` label +T-libs-api
|
|
platform-independent
|
|
|
|
|
|
|
|
Implement phantom variance markers
ACP accepted https://github.com/rust-lang/libs-team/issues/488
Tracking issue #135806
|
|
Clarify WindowsMut (Lending)Iterator
fixes #133628
|
|
fixes 133628
|
|
This has been unstably const since [1], but a tracking issue was never
created. Per discussion on Zulip [2], there should not be any blockers
to making this const-stable. The function does not provide any
functionality at compile time but does allow code reuse between const-
and non-const functions, so stabilize it here.
[1]: https://github.com/rust-lang/rust/pull/92226
[2]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
|
|
Rollup of 8 pull requests
Successful merges:
- #126604 (Uplift `clippy::double_neg` lint as `double_negations`)
- #135158 (Add `TooGeneric` variant to `LayoutError` and emit `Unknown`)
- #135635 (Move `std::io::pipe` code into its own file)
- #136072 (add two old crash tests)
- #136079 (compiler_fence: fix example)
- #136091 (Add some tracing to core bootstrap logic)
- #136097 (rustc_ast: replace some len-checks + indexing with slice patterns etc.)
- #136101 (triagebot: set myself on vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
|
|
compiler_fence: fix example
The old example was wrong, an acquire fence is required in the signal handler. To make the point more clear, I changed the "data" variable to use non-atomic accesses.
Fixes https://github.com/rust-lang/rust/issues/133014
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only))
- #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets)
- #135812 (Fix GDB `OsString` provider on Windows )
- #135842 (TRPL: more backward-compatible Edition changes)
- #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting)
- #135953 (ci.py: check the return code in `run-local`)
- #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls
Inspired by https://github.com/rust-lang/libs-team/issues/526, if people are looking for `unchecked_div`, point them to `u32: Div<NonZero<u32>>` and friends which do no runtime checks -- and are safe! -- rather than today's behaviour of [the intrinsic being the top result](https://doc.rust-lang.org/std/?search=unchecked_div).
|
|
|
|
Update emscripten std tests
This disables a bunch of emscripten tests that test things emscripten doesn't support and re-enables a whole bunch of tests which now work just fine on emscripten.
Tested with `EMCC_CFLAGS="-s MAXIMUM_MEMORY=2GB" ./x.py test library/ --target wasm32-unknown-emscripten`.
|
|
docs: fix typo in std::pin overview
Unimportant fix in `std::pin` documentation.
|
|
ports last few library files to new intrinsic style
This pr ports the last 2 library files to new intrinsic style this pr is part of issue #132735
|
|
Fix `FormattingOptions` instantiation with `Default`
The `fill` value by default should be set to `' '` (space), but the current implementation uses `#[derive(Default)]` which sets it to `\0`.
Note that `FormattingOptions` is being released as part of 1.85 (unstable) - so this might warrant a backport to that branch.
Tracking issue: https://github.com/rust-lang/rust/issues/118117
Follow up from https://github.com/rust-lang/rust/pull/118159
CC: ``@EliasHolzmann`` ``@programmerjake``
r? ``@m-ou-se``
|
|
|
|
|
