ensure that a macOS os_unfair_lock that is moved while being held is not implicitly unlocked
Fixes https://github.com/rust-lang/miri/issues/3859
We mark an os_unfair_lock that is moved while being held as "poisoned", which means it is not considered forever locked. That's not quite what the real implementation does, but allowing arbitrary moves-while-locked would likely expose a ton of implementation details, so hopefully this is good enough.
Also use outermost const-anon for impl items in `non_local_defs` lint
This PR update the logic for the impl paths (items) in the `non_local_definitions` lint to also consider const-anon in case the impl definition is wrapped inside const-anon it-self wrapped into a const-anon where the items are.
r? `@jieyouxu` *(since you interacted on the issue)*
Fixes *(after beta-backport)* #131643
merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate
https://github.com/rust-lang/rust/issues/76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to https://github.com/rust-lang/rust/issues/76205.
miri: avoid cloning AllocExtra
We shouldn't be cloning Miri allocations, so make `AllocExtra::clone` panic instead, and adjust the one case where we *do* clone (the leak check) to avoid cloning.
This is in preparation for https://github.com/rust-lang/miri/pull/3966 where I am adding something to `AllocExtra` that cannot (easily) be cloned.
r? ``@saethlin``
compiler: `{TyAnd,}Layout` comes home
The `Layout` and `TyAndLayout` types are heavily abstract and have no particular target-specific qualities, though we do use them to answer questions particular to targets. We can keep it that way if we simply move them out of `rustc_target` and into `rustc_abi`. They bring a small entourage of connected types with them, but that's fine.
This will allow us to strengthen a few abstraction barriers over time and thus make the notoriously gnarly layout code easier to refactor. For now, we don't need to worry about that and deliberately use reexports to minimize this particular diff.
core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments.
Adds:
- `Ipv4Address::from_octets([u8;4])`
- `Ipv6Address::from_octets([u8;16])`
- `Ipv6Address::from_segments([u16;8])`
equivalent to the existing `From` impls.
Advantages:
- Consistent with `to_bits, from_bits`.
- More discoverable than the `From` impls.
- Helps with type inference: it's common to want to convert byte slices to IP addrs. If you try this
```rust
fn foo(x: &[u8]) -> Ipv4Addr {
Ipv4Addr::from(foo.try_into().unwrap())
}
```
it [doesn't work](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2873312de275a58fa6e33d1b213bec). You have to write `Ipv4Addr::from(<[u8;4]>::try_from(x).unwrap())` instead, which is not great. With `from_octets` it is able to infer the right types.
Found this while porting [smoltcp](https://github.com/smoltcp-rs/smoltcp/) from its own IP address types to the `core::net` types.
~~Tracking issues #27709 #76205~~
Tracking issue: https://github.com/rust-lang/rust/issues/131360
std::fs::get_path freebsd update.
what matters is we re doing the right things as doing sizeof, rather than passing KINFO_FILE_SIZE (only defined on intel architectures), the kernel
making sure it matches the expectation in its side.
Rollup of 8 pull requests
Successful merges:
- #130356 (don't warn about a missing change-id in CI)
- #130900 (Do not output () on empty description)
- #131066 (Add the Chinese translation entry to the RustByExample build process)
- #131067 (Fix std_detect links)
- #131644 (Clean up some Miri things in `sys/windows`)
- #131646 (sys/unix: add comments for some Miri fallbacks)
- #131653 (Remove const trait bound modifier hack)
- #131659 (enable `download_ci_llvm` test)
r? `@ghost`
`@rustbot` modify labels: rollup
Clean up some Miri things in `sys/windows`
- remove miri hack that is only needed for win7 (we don't support win7 as a target in Miri)
- remove outdated comment now that Miri is on CI
Do not output () on empty description
When passing an explicitly empty description string, as explained here https://github.com/rust-lang/rust/blob/master/config.example.toml#L611-L613, my expectation is that the resulting rustc will be compatible with upstream.
However, it seems that instead, a `()` is added to the end of the version string, causing the version compatibility check to fail. My proposed fix here would be to instead only print `({description})` if `description` is a non-empty string.
