| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add an intrinsic for `ptr::metadata`
The follow-up to #123840, so we can remove `PtrComponents` and `PtrRepr` from libcore entirely (well, after a bootstrap update).
As discussed in <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/.60ptr_metadata.60.20in.20MIR/near/435637808>, this introduces `UnOp::PtrMetadata` taking a raw pointer and returning the associated metadata value.
By no longer going through a `union`, this should also help future PRs better optimize pointer operations.
r? ``@oli-obk``
|
|
|
|
|
|
rustfmt fixes
The `rmake.rs` entries in `rustfmt.toml` are causing major problems for `x fmt`. This PR removes them and does some minor related cleanups.
r? ``@GuillaumeGomez``
|
|
It's reasonable to want to, but in the current implementation this
causes multiple problems.
- All the `rmake.rs` files are formatted every time even when they
haven't changed. This is because they get whitelisted unconditionally
in the `OverrideBuilder`, before the changed files get added.
- The way `OverrideBuilder` works, if any files gets whitelisted then no
unmentioned files will get traversed. This is surprising, and means
that the `rmake.rs` entries broke the use of explicit paths to `x
fmt`, and also broke `GITHUB_ACTIONS=true git check --fmt`.
The commit removes the `rmake.rs` entries, fixes the formatting of a
couple of files that were misformatted (not previously caught due to the
`GITHUB_ACTIONS` breakage), and bans `!`-prefixed entries in
`rustfmt.toml` because they cause all these problems.
|
|
update tracking issue for lazy_cell_consume
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
|
|
Stabilise `IpvNAddr::{BITS, to_bits, from_bits}` (`ip_bits`)
This completed FCP in #113744. (Closes #113744.)
Stabilises the following APIs:
```rust
impl Ipv4Addr {
pub const BITS: u32 = 32;
pub const fn from_bits(bits: u32) -> Ipv4Addr;
pub const fn to_bits(self) -> u32;
}
impl Ipv6Addr {
pub const BITS: u32 = 128;
pub const fn from_bits(bits: u128) -> Ipv4Addr;
pub const fn to_bits(self) -> u128;
}
```
|
|
|
|
Always use the general case char count with `optimize_for_size`
The faster algo is really expensive, over a kilobyte if the full algo is present in a binary.
With this PR the general case algo is picked always instead of only for small strings.
In a test of mine this change makes the total binary go from 3116 bytes to 2032 bytes in opt-level 3 and from 1652 bytes to 1428 bytes in opt-level z. I've seen it much worse in real application, so the savings (especially on 'z') will be higher in many cases.
This is the second pr of this kind after #125606
|
|
Update Result docs to the new guarantees
The `Option` docs already explain the guarantees given in [RFC 3391](https://github.com/rust-lang/rfcs/blob/master/text/3391-result_ffi_guarantees.md), so all that we need is a paragraph saying that some `Result` type combinations will also qualify.
Part of https://github.com/rust-lang/rust/issues/110503
|
|
|
|
|
|
Simplify the `unchecked_sh[lr]` ub-checks a bit
It can use the constant in the check, rather than passing it as a parameter.
|
|
f32: use constants instead of reassigning a dummy value as PI
|
|
Stabilize `slice_flatten`
|
|
|
|
|
|
Move the checks for Arguments constructors to inline const
Thanks `@Skgland` for pointing out this opportunity: https://github.com/rust-lang/rust/pull/117804#discussion_r1612964362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize `div_duration`
Closes #63139
|
|
Fix c_char on AIX
Closes https://github.com/rust-lang/rust/issues/122985
|
|
Stabilize `LazyCell` and `LazyLock`
Closes #109736
This stabilizes the [`LazyLock`](https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html) and [`LazyCell`](https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html) types:
```rust
static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
println!("initializing");
let mut m = HashMap::new();
m.insert(13, "Spica".to_string());
m.insert(74, "Hoyten".to_string());
m
});
let lazy: LazyCell<i32> = LazyCell::new(|| {
println!("initializing");
92
});
```
r? libs-api
|
|
|
|
Add assert_unsafe_precondition to unchecked_{add,sub,neg,mul,shl,shr} methods
(Old PR is haunted, opening a new one. See #117494 for previous discussion.)
This ensures that these preconditions are actually checked in debug mode, and hopefully should let people know if they messed up. I've also replaced the calls (I could find) in the code that use these intrinsics directly with those that use these methods, so that the asserts actually apply.
More discussions on people misusing these methods in the tracking issue: https://github.com/rust-lang/rust/issues/85122.
|
|
|
|
Fix some SIMD intrinsics documentation
Spotted some mistakes in the docs of some SIMD intrinsics.
|
|
While the semantic intent of a OnceCell/OnceLock is that it can only be written
to once (upon init), the fact of the matter is that both these types offer a
`take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell
to its initial state, thereby technically allowing it to be written to again.
Despite the fact that this can only happen with a mutable reference (generally
only used during the construction of the OnceCell/OnceLock), it would be
incorrect to say that the type itself as a whole categorically prevents being
initialized or written to more than once (since it is possible to imagine an
identical type only without the `take()` method that actually fulfills that
contract).
To clarify, change "that cannot be.." to "that nominally cannot.." and add a
note to OnceCell about what can be done with an `&mut Self` reference.
|
|
Make `clamp` inline
Context: rust-lang/rust-clippy#12826
This results in slightly more optimized assembly. (And most important, it's now less than lines than just manually clamping a value)
|
|
|
|
Add a fast-path to `Debug` ASCII `&str`
Instead of going through the `EscapeDebug` machinery, we can just skip over ASCII chars that don’t need any escaping.
---
This is an alternative / a companion to https://github.com/rust-lang/rust/pull/121138.
The other PR is adding the fast path deep within `EscapeDebug`, whereas this skips as early as possible.
|
|
Validate the special layout restriction on `DynMetadata`
If you look at <https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/std/ptr/struct.DynMetadata.html>, you'd think that `DynMetadata` is a struct with fields.
But it's actually not, because the lang item is special-cased in rustc_middle layout:
https://github.com/rust-lang/rust/blob/7601adcc764d42c9f2984082b49948af652df986/compiler/rustc_middle/src/ty/layout.rs#L861-L864
That explains the very confusing codegen ICEs I was getting in https://github.com/rust-lang/rust/pull/124251#issuecomment-2128543265
> Tried to extract_field 0 from primitive OperandRef(Immediate((ptr: %5 = load ptr, ptr %4, align 8, !nonnull !3, !align !5, !noundef !3)) @ TyAndLayout { ty: DynMetadata<dyn Callsite>, layout: Layout { size: Size(8 bytes), align: AbiAndPrefAlign { abi: Align(8 bytes), pref: Align(8 bytes) }, abi: Scalar(Initialized { value: Pointer(AddressSpace(0)), valid_range: 1..=18446744073709551615 }), fields: Primitive, largest_niche: Some(Niche { offset: Size(0 bytes), value: Pointer(AddressSpace(0)), valid_range: 1..=18446744073709551615 }), variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(8 bytes) } })
because there was a `Field` projection despite the layout clearly saying it's [`Primitive`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/abi/enum.FieldsShape.html#variant.Primitive).
Thus this PR updates the MIR validator to check for such a projection, and changes `libcore` to not ever emit any projections into `DynMetadata`, just to transmute the whole thing when it wants a pointer.
|
|
|
|
|
|
Actually use TAIT instead of emulating it
`core`'s `impl_fn_for_zst` macro is just a hacky way of emulating TAIT. TAIT has become stable enough to be used [in other places](https://github.com/rust-lang/rust/blob/e8fbd991287f637f95016a71ddc13438415bbe59/library/std/src/backtrace.rs#L431) inside the standard library, so let's use it in `core` as well.
|
|
This avoids having to collect a non-ASCII-printable run before processing it.
|
|
Panic directly in Arguments::new* instead of recursing
This has been bothering me because it looks very silly in MIR.
|
|
|
|
|
|
|
|
Wrap Context.ext in AssertUnwindSafe
Fixes https://github.com/rust-lang/rust/issues/125193
Alternative to https://github.com/rust-lang/rust/pull/125377
Relevant to https://github.com/rust-lang/rust/issues/123392
I believe this approach is justifiable due to the fact that this function is unstable API and we have been considering trying to dispose of the notion of "unwind safety". Making a more long-term decision should be considered carefully as part of stabilizing `fn ext`, if ever.
r? `@Amanieu`
|
|
Rollup of 7 pull requests
Successful merges:
- #125043 (reference type safety invariant docs: clarification)
- #125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
- #125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
- #125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
- #125391 (Minor serialize/span tweaks)
- #125395 (Remove unnecessary `.md` from the documentation sidebar)
- #125399 (Stop using `to_hir_binop` in codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
reference type safety invariant docs: clarification
The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.
I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.
I also took a clarification from https://github.com/rust-lang/rust/pull/121965 that is orthogonal to the rest of that PR.
Cc ```@joshlf``` ```@scottmcm```
|
|
miri: rename intrinsic_fallback_checks_ub to intrinsic_fallback_is_spec
Checking UB is not the only concern, we also have to make sure we are not losing out on non-determinism.
r? ``@oli-obk`` (not urgent, take your time)
|
|
offset: allow zero-byte offset on arbitrary pointers
As per prior `@rust-lang/opsem` [discussion](https://github.com/rust-lang/opsem-team/issues/10) and [FCP](https://github.com/rust-lang/unsafe-code-guidelines/issues/472#issuecomment-1793409130):
- Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer
- Inbounds-offset-by-zero is allowed on all pointers, including the null pointer
- `offset_from` on two pointers derived from the same allocation is always allowed when they have the same address
This removes surprising UB (in particular, even C++ allows "nullptr + 0", which we currently disallow), and it brings us one step closer to an important theoretical property for our semantics ("provenance monotonicity": if operations are valid on bytes without provenance, then adding provenance can't make them invalid).
The minimum LLVM we require (v17) includes https://reviews.llvm.org/D154051, so we can finally implement this.
The `offset_from` change is needed to maintain the equivalence with `offset`: if `let ptr2 = ptr1.offset(N)` is well-defined, then `ptr2.offset_from(ptr1)` should be well-defined and return N. Now consider the case where N is 0 and `ptr1` dangles: we want to still allow offset_from here.
I think we should change offset_from further, but that's a separate discussion.
Fixes https://github.com/rust-lang/rust/issues/65108
[Tracking issue](https://github.com/rust-lang/rust/issues/117945) | [T-lang summary](https://github.com/rust-lang/rust/pull/117329#issuecomment-1951981106)
Cc `@nikic`
|
