feat: Add `bit_width` for unsigned `NonZero<T>`
- Tracking issue: rust-lang/rust#142326
This pull request adds a method to the unsigned `NonZero<T>` that return the minimum number of bits required to represent a value.
This can be achieved by using the `get` method and the methods added in rust-lang/rust#142328, but I think adding the `NonZero::bit_width` method is useful because it accomplishes the same thing a little more succinctly.
Make SIMD intrinsics available in `const`-contexts
successor to rust-lang/rust#146568, this PR actually makes the SIMD intrinsics `const`, and modifies the tests to test the const-eval implementations
r? `@tgross35` ig (although feel free to reassign, this is not anything targeted really)
Add check if span is from macro expansion
The same thing I did in https://github.com/rust-lang/rust/pull/147416, actually the same bug but in another place, I'm not really sure how this method is good for fixing such ICEs, but, it does work and not conflicting with any existing tests, so I guess, it's fine
Fixes https://github.com/rust-lang/rust/issues/147408
r? compiler
recommend using a HashMap if a HashSet's second generic parameter doesn't implement BuildHasher
closesrust-lang/rust#147147
~The suggestion span is wrong, but I'm not sure how to find the right one.~ fixed
I'm relatively new to the diagnostics ecosystem, so I'm not sure if `span_help` is the right choice. `span_suggestion_*` might be better, but the output from `x test` looks weird in that case.
Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
debug-assert FixedSizeEncoding invariant
Something like this? It asserts during encoding that for that type, decoding 0 would give the default.
Preferably, I'd either somehow statically/in const assert it once, instead of every time, but I see no easy way to do so. It'd require us to iterate all types that implement the trait or something. Let me know what you think
No types currently violate this invariant.
r? `@oli-obk`
repr(transparent) check: do not compute check_unsuited more than once
`field_infos` is an iterator that we execute multiple times. However, we usually ignore the `unsuited` field -- we only need it in the last iteration. So move the computation of that field to that iteration to avoid computing it multiple times. Computing `unsuited` involves a recursive traversal over the types of all non-trivial fields, so there can be non-trivial amounts of work here.
(I benchmarked this in https://github.com/rust-lang/rust/pull/148243 and saw no changes, probably because we don't have a benchmark with many repr(transparent) types. But still, computing this each time just seemed silly.)
Improve the documentation of atomic::fence
Attempt to "fix" two flaws of the current documentation:
1. The over-emphasis of fence - fence synchronization, relegating atomic - fence and fence - atomic synchronization to second fiddle.
2. The lack of explanation as to how to properly perform atomic - fence and fence - atomic synchronization.
It does so by first making it clear that there are 3 different ways to use an atomic fence, then presenting a full example for each usecase, noting the particular position of the fence with regard to the atomic operation, and rounding up with generic notes.
compiletest: Use JSON "binary-format" to decide `//@ only-elf` and `//@ ignore-elf`
Some tests only apply to ELF targets, or want to enable different test revisions for ELF and non-ELF targets. So compiletest supports the `//@ only-elf` and `//@ ignore-elf` directives to make that possible.
Historically, deciding whether the current target is an ELF target relied on a handful of ad-hoc string comparisons against the target tuple.
However, nowadays compiletest has access to the output of `--print=all-target-specs-json`, and that JSON output specifies the binary format of each target, making it much easier to determine whether a target is ELF or not.
flush_delayed: add note about stashed diagnostics
r? `@nnethercote`
Is `emit_stashed_diagnostics` the right advice to give? The other option seems to be to call `finish_diagnostics`. That's what I ended up doing (for now) in https://github.com/rust-lang/miri/pull/4702 because it best matches what happens during normal compilation.
Replace OffsetOf by an actual sum of calls to intrinsic.
This PR changes the way we compute the value of the `offset_of!` macro in MIR. The current implementation uses a dedicated MIR rvalue.
This PR proposes to replace it by an inline constant which sums calls to a new intrinsic `offset_of(variant index, field index)`. The desugaring is done at THIR building time, easier that doing it on MIR.
The new intrinsic is only meant to be used by const-eval. LLVM codegen will refuse to generate code for it.
We replace:
```rust
a = offset_of!(T, Variant1.Field1.Variant2.Field2);
```
By:
```rust
a = const {constant#n};
{constant#n}: usize = {
_1 = offset_of::<T>(index of Variant1, index of Field1);
_2 = offset_of::<U>(index of Variant2, index of Field2); // Where T::Variant1::Field1 has type U
_0 = _1 + _2
}
```
The second commit modifies intrinsic const checking to take `allow_internal_unstable` into account. The new intrinsic should only be called from stable `offset_of!` macro. The intrinsic itself is unstable, const-unstable, but `rustc_intrinsic_const_stable_indirect`.
Fixesrust-lang/rust#123959Fixesrust-lang/rust#125680Fixesrust-lang/rust#129425Fixesrust-lang/rust#136175
r? `@ghost`
Build with -Zannotate-moves by default (non-stage-0 only)
Build rustc and tools with -Zannotate-moves by default, both to exercise the feature and because could be useful for doing performance measurement on rustc and its tools. This has no effect on generated code, it just adds extra debug info in
the form of some new inlined functions.
This also adds bootstrap.toml config options
```
# rust.annotate-moves = true
# rust.annotate-moves-size-limit = 65
```
to allow this to be controlled locally.
This is only added for stage 1 and later. Stage 0 (the bootstrap compiler) doesn't yet support -Zannotate-moves.
std: move `kernel_copy` to `sys`
Part of rust-lang/rust#117276.
The current organisation of the `kernel_copy` mechanism used to specialise `io::copy` on Linux necessitated circular links between the `io::copy` module and the implementation in `sys::pal::unix::kernel_copy`, as well as presenting an exception to the tidy PAL rule that forbids OS-based `#[cfg]`s outside of `sys` and `os`.
This PR fixes this by moving `kernel_copy` to `sys` (as per rust-lang/rust#117276) and returning a `CopyState` from that function specifying whether `io::copy` should use its fallback. The `kernel_copy` function on other platforms just unconditionally returns `CopyState::Fallback`.
Build rustc and tools with -Zannotate-moves by default. Adds toml config
options to set the annotation size limit.
This has no measurable effect on output binary size or compile time.
Matthias Krüger