miri: improve errors for type validity assertion failures
Miri has pretty nice errors for type validity violations, printing which field in the type the problem occurs at and so on.
However, we don't see these errors when using e.g. `mem::zeroed` as that uses `assert_zero_valid` to bail out before Miri can detect the UB.
Similar to what we did with `@saethlin's` UB checks, I think we should disable such language UB checks in Miri so that we can get better error messages. If we go for this we should probably say this in the intrinsic docs as well so that people don't think they can rely on these intrinsics catching anything.
Furthermore, I slightly changed `MaybeUninit::assume_init` so that the `.value` field does not show up in error messages any more.
`@rust-lang/miri` what do you think?
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`)
- rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore)
- rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`)
- rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`)
- rust-lang/rust#142237 (Detect more cases of unused_parens around types)
- rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments)
- rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself)
- rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too)
- rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`)
- rust-lang/rust#143276 (loop match: handle opaque patterns)
- rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`
Also applies to `Vec::into_raw_parts`.
The expectation is that you can round-trip these methods with `from_raw`, but this is only true when using the global allocator. With custom allocators you should instead be using `into_raw_with_allocator` and `from_raw_in`.
The implementation of `Box::leak` is changed to use `Box::into_raw_with_allocator` and explicitly leak the allocator (which was already the existing behavior). This is because, for `leak` to be safe, the allocator must not free its underlying backing store. The `Allocator` trait only guarantees that allocated memory remains valid until the allocator is dropped.
Remove some unsized tuple impls now that we don't support unsizing tuples anymore
Since https://github.com/rust-lang/rust/pull/137728 there is no sound way to create unsized tuples anymore. While we can't remove them from the language (tried here: https://github.com/rust-lang/rust/pull/138093) due to people using `PhantomData<(T, U)>` where `U: ?Sized` (they'd have to use `(PhantomData<T>, PhantomData<U>)` now), we can remove the impls from libcore I believe.
r? libs I guess?
Derive `Copy` and `Hash` for `IntErrorKind`
This PR derives `Copy` and `Hash` for `IntErrorKind` to make it easier to work with. (see #131826)
I think an argument could be made to also derive `PartialOrd` + `Ord` as well given that other error kinds in the std like [`io::ErrorKind`](https://doc.rust-lang.org/src/std/io/error.rs.html#212-428) do this. Granted these seem much less useful for errors.
Fixes https://github.com/rust-lang/rust/issues/131826
Also applies to `Vec::into_raw_parts`.
The expectation is that you can round-trip these methods with
`from_raw`, but this is only true when using the global allocator. With
custom allocators you should instead be using
`into_raw_with_allocator` and `from_raw_in`.
The implementation of `Box::leak` is changed to use
`Box::into_raw_with_allocator` and explicitly leak the allocator (which
was already the existing behavior). This is because, for `leak` to be
safe, the allocator must not free its underlying backing store. The
`Allocator` trait only guarantees that allocated memory remains valid
until the allocator is dropped.
Implement `Random` for tuple
Implement `Random` for tuples of arity 12 or less. Each element is expected to implement `Random`.
I think it's OK to implement this trait for the following types:
- Primitive integer types and `bool`
- Arrays and tuples of the above values
- ~~`NonZero<T>`~~, `Saturating<T>` and `Wrapping<T>`
The necessity of this trait is debated (<https://github.com/rust-lang/rust/issues/130703#issuecomment-2508889577>), but if we decide to keep it in the future when the `random` module is stabilized, I think it would be useful to have this trait implemented for tuples.
Tracking issue: #130703
r? `@joboet`
Workaround for memory unsafety in third party DLLs
Resolvesrust-lang/rust#143078
Note that we can't make any guarantees if third parties intercept OS functions and don't implement them according to the documentation. However, I think it's practical to attempt mitigations when issues are encountered in the wild and the mitigation itself isn't too invasive.
Add SIMD funnel shift and round-to-even intrinsics
This PR adds 3 new SIMD intrinsics
- `simd_funnel_shl` - funnel shift left
- `simd_funnel_shr` - funnel shift right
- `simd_round_ties_even` (vector version of `round_ties_even_fN`)
TODO (future PR): implement `simd_fsh{l,r}` in miri, cg_gcc and cg_clif (it is surprisingly hard to implement without branches, the common tricks that rotate uses doesn't work because we have 2 elements now. e.g, the `-n&31` trick used by cg_gcc to implement rotate doesn't work with this because then `fshl(a, b, 0)` will be `a | b`)
[#t-compiler > More SIMD intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/More.20SIMD.20intrinsics/with/522130286)
`@rustbot` label T-compiler T-libs A-intrinsics F-core_intrinsics
r? `@workingjubilee`
BTreeSet: remove duplicated code by reusing `from_sorted_iter`
The method `BTreeSet::from_sorted_iter` was introduced in 49ccb7519f, but it was not consistently used throughout the codebase. As a result, some code redundantly reimplemented its logic. This commit fixes the problem.
update internal `send_signal` comment
the vxwork did not have the old comment updated in rust-lang/rust#141990 so update here;
signaling -> sending signals to because the latter reads better to me.
Do not include NUL-terminator in computed length
This PR contains just the first commit of rust-lang/rust#142579 which changes it so that the string length stored in the `Location` is the length of the `&str` rather than the length of the `&CStr`. Since most users will want the `&str` length, it seems better to optimize for that use-case.
There should be no visible changes in the behavior or API.
std::net: adding `unix_socket_exclbind` feature for solaris/illumos.
allows to have a tigher control over the binding exclusivness of the socket.
ACP: https://github.com/rust-lang/libs-team/issues/366
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
The method `BTreeSet::from_sorted_iter` was introduced in 49ccb7519f,
but it was not consistently used throughout the codebase. As a result, some code redundantly reimplemented its logic.
This commit fixes the problem.
Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
Fix RwLock::try_write documentation for WouldBlock condition
Fix RwLock::try_write documentation for WouldBlock condition
The documentation incorrectly stated that try_write only fails when
'already locked exclusively', but it actually fails when there are
either shared (read) or exclusive (write) locks.
Fixesrust-lang/rust#142852
Remove incorrect comments in `Weak`
It is currently possible to create a dangling `Weak` to a DST by calling `Weak::new()` for a sized type, then doing an unsized coercion. Therefore, the comments are wrong.
These comments were added in <https://github.com/rust-lang/rust/pull/73845>. As far as I can tell, the guarantee in the comment was only previously used in the `as_ptr` method. However, the current implementation of `as_ptr` no longer relies on this guarantee.
small iter.intersperse.fold() optimization
No need to call into fold when the first item is already None, this avoids some redundant work for empty iterators.
"But it uses Fuse" one might want to protest, but Fuse is specialized and may call into the inner iterator anyway.
make RefCell unstably const
Now that we can do interior mutability in `const`, most of the `RefCell` API can be `const fn`. The main exceptions are APIs which use `FnOnce` (`RefCell::replace_with` and `Ref[Mut]::[filter_]map[_split]`) and `RefCell::take` which calls `Default::default`.
Tracking issue: #137844
