| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #123198 (Add fn const BuildHasherDefault::new)
- #123226 (De-LLVM the unchecked shifts [MCP#693])
- #123302 (Make sure to insert `Sized` bound first into clauses list)
- #123348 (rustdoc: add a couple of regression tests)
- #123362 (Check that nested statics in thread locals are duplicated per thread.)
- #123368 (CFI: Support non-general coroutines)
- #123375 (rustdoc: synthetic auto trait impls: accept unresolved region vars for now)
- #123378 (Update sysinfo to 0.30.8)
Failed merges:
- #123349 (Fix capture analysis for by-move closure bodies)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
We will lose `f16` and `f128` in the beta compiler after the revert for
<https://github.com/rust-lang/rust/issues/123282> lands. Change what was
added in <https://github.com/rust-lang/rust/pull/123085> to be behind
`#[cfg(not(bootstrap))]` to account for this.
|
|
De-LLVM the unchecked shifts [MCP#693]
This is just one part of the MCP (https://github.com/rust-lang/compiler-team/issues/693), but it's the one that IMHO removes the most noise from the standard library code.
Seems net simpler this way, since MIR already supported heterogeneous shifts anyway, and thus it's not more work for backends than before.
r? WaffleLapkin
|
|
Add fn const BuildHasherDefault::new
See [tracking issue](https://github.com/rust-lang/rust/issues/123197) for justification.
|
|
Add `Ord::cmp` for primitives as a `BinOp` in MIR
Update: most of this OP was written months ago. See https://github.com/rust-lang/rust/pull/118310#issuecomment-2016940014 below for where we got to recently that made it ready for review.
---
There are dozens of reasonable ways to implement `Ord::cmp` for integers using comparison, bit-ops, and branches. Those differences are irrelevant at the rust level, however, so we can make things better by adding `BinOp::Cmp` at the MIR level:
1. Exactly how to implement it is left up to the backends, so LLVM can use whatever pattern its optimizer best recognizes and cranelift can use whichever pattern codegens the fastest.
2. By not inlining those details for every use of `cmp`, we drastically reduce the amount of MIR generated for `derive`d `PartialOrd`, while also making it more amenable to MIR-level optimizations.
Having extremely careful `if` ordering to μoptimize resource usage on broadwell (#63767) is great, but it really feels to me like libcore is the wrong place to put that logic. Similarly, using subtraction [tricks](https://graphics.stanford.edu/~seander/bithacks.html#CopyIntegerSign) (#105840) is arguably even nicer, but depends on the optimizer understanding it (https://github.com/llvm/llvm-project/issues/73417) to be practical. Or maybe [bitor is better than add](https://discourse.llvm.org/t/representing-in-ir/67369/2?u=scottmcm)? But maybe only on a future version that [has `or disjoint` support](https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036?u=scottmcm)? And just because one of those forms happens to be good for LLVM, there's no guarantee that it'd be the same form that GCC or Cranelift would rather see -- especially given their very different optimizers. Not to mention that if LLVM gets a spaceship intrinsic -- [which it should](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Suboptimal.20inlining.20in.20std.20function.20.60binary_search.60/near/404250586) -- we'll need at least a rustc intrinsic to be able to call it.
As for simplifying it in Rust, we now regularly inline `{integer}::partial_cmp`, but it's quite a large amount of IR. The best way to see that is with https://github.com/rust-lang/rust/commit/8811efa88b25b5e41d63850e6047e8257c677858#diff-d134c32d028fbe2bf835fef2df9aca9d13332dd82284ff21ee7ebf717bfa4765R113 -- I added a new pre-codegen MIR test for a simple 3-tuple struct, and this PR change it from 36 locals and 26 basic blocks down to 24 locals and 8 basic blocks. Even better, as soon as the construct-`Some`-then-match-it-in-same-BB noise is cleaned up, this'll expose the `Cmp == 0` branches clearly in MIR, so that an InstCombine (#105808) can simplify that to just a `BinOp::Eq` and thus fix some of our generated code perf issues. (Tracking that through today's `if a < b { Less } else if a == b { Equal } else { Greater }` would be *much* harder.)
---
r? `@ghost`
But first I should check that perf is ok with this
~~...and my true nemesis, tidy.~~
|
|
|
|
improve example on inserting to a sorted vector to avoid shifting equal elements
|
|
|
|
doc: describe panic conditions for SliceIndex implementations
Implementation note: The most probable place for users to find the documentation is at https://doc.rust-lang.org/std/slice/trait.SliceIndex.html
On that page, documentation added to specific methods will not be visible. As such, I opted to add the comments to the impl blocks directly.
Helps with #121568.
|
|
|
|
Implementation note: The most probable place for users to find
the documentation is at https://doc.rust-lang.org/std/slice/trait.SliceIndex.html
On that page, documentation added to specific methods will not
be visible. As such, I opted to add the comments to the impl blocks
directly.
Helps with #121568.
|
|
So pointee metadata can be used in anonymous statics.
This is prerequisite for implementing ThinBox without allocation for
ZST.
See https://github.com/rust-lang/rust/pull/123184#discussion_r1544627488
|
|
Require Debug for Pointee::Metadata
Useful for debugging.
|
|
Add basic trait impls for `f16` and `f128`
Split off part of <https://github.com/rust-lang/rust/pull/122470> so the compiler doesn't ICE because it expects primitives to have some minimal traits.
Fixes <https://github.com/rust-lang/rust/issues/123074>
|
|
Make {integer}::from_str_radix constant
This commit makes FromStr on integers constant so that `const x: u32 = "23".parse();` works. More practical use-case is with environment variables at build time as discussed in https://github.com/rust-lang/rfcs/issues/1907.
Tracking issue #59133.
ACP: https://github.com/rust-lang/libs-team/issues/74
|
|
Improve wording in std::any explanation
Prefer 'log' over 'log out' to avoid confusion, and use backticks consistently.
|
|
|
|
This is just one part of the MCP, but it's the one that IMHO removes the most noise from the standard library code.
Seems net simpler this way, since MIR already supported heterogeneous shifts anyway, and thus it's not more work for backends than before.
|
|
This is an alternative to #121920
|
|
Stabilize `unchecked_{add,sub,mul}`
Tracking issue: #85122
I think we might as well just stabilize these basic three. They're the ones that have `nuw`/`nsw` flags in LLVM.
Notably, this doesn't include the potentially-more-complex or -more-situational things like `unchecked_neg` or `unchecked_shr` that are under different feature flags.
To quote Ralf https://github.com/rust-lang/rust/issues/85122#issuecomment-1681669646,
> Are there any objections to stabilizing at least `unchecked_{add,sub,mul}`? For those there shouldn't be any surprises about what their safety requirements are.
*Semantially* these are [already available on stable, even in `const`, via](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bdb1ff889b61950897f1e9f56d0c9a36) `checked_*`+`unreachable_unchecked`. So IMHO we might as well just let people write them directly, rather than try to go through a `let Some(x) = x.checked_add(y) else { unsafe { hint::unreachable_unchecked() }};` dance.
I added additional text to each method to attempt to better describe the behaviour and encourage `wrapping_*` instead.
r? rust-lang/libs-api
|
|
|
|
Add detection of [Partial]Ord methods in the `ambiguous_wide_pointer_comparisons` lint
Partially addresses https://github.com/rust-lang/rust/issues/121264 by adding diagnostics items for PartialOrd and Ord methods, detecting such diagnostics items as "binary operation" and suggesting the correct replacement.
I also took the opportunity to change the suggestion to use new methods `.cast()` on `*mut T` an d `*const T`.
|
|
|
|
Prefer 'log' over 'log out' to avoid confusion, and use backticks consistently.
|
|
Because `HashMap::with_hasher` constness is being stabilized this will
in turn allow creating empty HashMap<K,V,BuildHasherDefault<H>> in const
context for any H: Default + Hasher.
|
|
|
|
|
|
Optimize `core::char::CaseMappingIter`
Godbolt says this saves a few instructions…
`@rustbot` label T-libs A-layout C-optimization
|
|
Useful for debugging
|
|
Eliminate `UbChecks` for non-standard libraries
The purpose of this PR is to allow other passes to treat `UbChecks` as constants in MIR for optimization after #122629.
r? RalfJung
|
|
Codegen const panic messages as function calls
This skips emitting extra arguments at every callsite (of which there
can be many). For a librustc_driver build with overflow checks enabled,
this cuts 0.7MB from the resulting shared library (see [perf]).
A sample improvement from nightly:
```
leaq str.0(%rip), %rdi
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdx
movl $25, %esi
callq *_ZN4core9panicking5panic17h17cabb89c5bcc999E@GOTPCREL(%rip)
```
to this PR:
```
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdi
callq *_RNvNtNtCsduqIKoij8JB_4core9panicking11panic_const23panic_const_div_by_zero@GOTPCREL(%rip)
```
[perf]: https://perf.rust-lang.org/compare.html?start=a7e4de13c1785819f4d61da41f6704ed69d5f203&end=64fbb4f0b2d621ff46d559d1e9f5ad89a8d7789b&stat=instructions:u
|
|
Split off part of <https://github.com/rust-lang/rust/pull/122470> so the
compiler doesn't ICE because it expects primitives to have some minimal
traits.
Fixes <https://github.com/rust-lang/rust/issues/123074>
|
|
Bump Unicode printables to version 15.1, align to unicode_data
r? `@Manishearth`
Thanks!
|
|
|
|
`num::NonZero::get` can be 1 transmute instead of 2
Just something I noticed in passing. No need for a `match` in here to call `unreachable_unchecked`, as `transmute_unchecked` will add the appropriate `llvm.assume` <https://rust.godbolt.org/z/W5hjeETnc>.
|
|
chore: fix some comments
|
|
Clarify atomic bit validity
The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`.
Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. https://github.com/google/zerocopy/issues/251).
|
|
|
|
Signed-off-by: xiaoxiangxianzi <zhaoyizheng@outlook.com>
|
|
|
|
See also https://github.com/rust-lang/rust/issues/74465#issuecomment-1676522051
Signed-off-by: tison <wander4096@gmail.com>
|
|
Soft-destabilize `RustcEncodable` & `RustcDecodable`, remove from prelude in next edition
cc rust-lang/libs-team#272
Any use of `RustcEncodable` and `RustcDecodable` now triggers a deny-by-default lint. The derives have been removed from the 2024 prelude. I specifically chose **not** to document this in the module-level documentation, as the presence in existing preludes is not documented (which I presume is intentional).
This does not implement the proposed change for `rustfix`, which I will be looking into shortly.
With regard to the items in the preludes being stable, this should not be an issue because #15702 has been resolved.
r? libs-api
|
|
Require `DerefMut` and `DerefPure` on `deref!()` patterns when appropriate
Waiting on the deref pattern syntax pr to merge
r? nadrieril
|
|
|
|
|
|
|
|
Import the 2021 prelude in the core crate
The `core` crate currently imports the v1 prelude
https://github.com/rust-lang/rust/blob/b3df0d7e5ef5f7dbeeca3fb289c65680ad013f87/library/core/src/lib.rs#L285-L287
This recently caused an issue when updating the `portable-simd` subtree since it was using a trait that was added to the 2021 prelude: https://github.com/rust-lang/rust/pull/122905#discussion_r1536228822
To make it easier to have a consistent build environment for subtrees and submodules that get included in `core`, we will now import the 2021 prelude into `core`.
Fixes #122912
r? `@Nilstrieb`
|
|
Update stdarch submodule
r? ```@Amanieu```
|
|
|
