Avoid mem::uninitialized() in std::sys::unix
For `libc` types that will be initialized in FFI calls, we can just use
`MaybeUninit` and then pass around raw pointers.
For `sun_path_offset()`, which really wants `offset_of`, all callers
have a real `sockaddr_un` available, so we can use that reference.
r? @RalfJung
This commit moves a test out of libstd which is causing deadlocks on
musl on CI. Looks like the recent update in musl versions brings in some
internal updates to musl which makes `setgid` and `setuid` invalid to
call after a `fork` in a multithreaded program. The issue seen here is
that the child thread was attempting to grab a lock held by a
nonexistent thread, meaning that the child process simply deadlocked
causing the whole test to deadlock.
This commit moves the test to its own file with no threads which should
work.
For `libc` types that will be initialized in FFI calls, we can just use
`MaybeUninit` and then pass around raw pointers.
For `sun_path_offset()`, which really wants `offset_of`, all callers
have a real `sockaddr_un` available, so we can use that reference.
macos tlv workaround
fixes: #60141
Includes:
* remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655)
* redox had a copy of `fast::Key` (not sure why?). That has been removed.
* Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1.
`tlv_get_addr` is relatively expensive (~1.5ns on my machine).
Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match.
After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined.
I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither.
r? @alexcrichton
Refactor C FFI variadics to more closely match their C counterparts, and add Clone implementation
We had to make some changes to expose `va_copy` and `va_end` directly to users (mainly for C2Rust, but not exclusively):
- redefine the Rust variadic structures to more closely correspond to C: `VaList` now matches `va_list`, and `VaListImpl` matches `__va_list_tag`
- add `Clone` for `VaListImpl`
- add explicit `as_va_list()` conversion function from `VaListImpl` to `VaList`
- add deref coercion from `VaList` to `VaListImpl`
- add support for the `asmjs` target
All these changes were needed for use cases like:
```Rust
let mut ap2 = va_copy(ap);
vprintf(fmt, ap2);
va_end(&mut ap2);
```
std: Remove internal definitions of `cfg_if!` macro
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
Increases heap size available during testing for SGX
PR [61540](https://github.com/rust-lang/rust/pull/61540) causes at least one test to fail when run for the SGX platform due to lack of memory. This PR increases the heapsize available during tests, which is a good thing regardless of the status of that PR.
Implementation of RFC 2289 (associated_type_bounds)
This PR implements the [`asociated_type_bounds` feature](https://github.com/rust-lang/rfcs/blob/master/text/2289-associated-type-bounds.md).
Associated type bounds are implemented in:
- function/method arguments and return types
- structs, enums, unions
- associated items in traits
- type aliases
- type parameter defaults
- trait objects
- let bindings
CC @nikomatsakis @centril
std: Update dependency on `backtrace`
Discovered in #61416 an accidental regression in libstd's backtrace
behavior is that it previously attempted to consult libbacktrace and
would then fall back to `dladdr` if libbacktrace didn't report anything.
The `backtrace` crate, however, did not do this, so that's now been
fixed!
Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.29Closes#61416
Discovered in #61416 an accidental regression in libstd's backtrace
behavior is that it previously attempted to consult libbacktrace and
would then fall back to `dladdr` if libbacktrace didn't report anything.
The `backtrace` crate, however, did not do this, so that's now been
fixed!
Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.27Closes#61416
std::net: Ipv4Addr and Ipv6Addr improvements
Picking this up again from my previous PR: https://github.com/rust-lang/rust/pull/56050
Related to: https://github.com/rust-lang/rust/issues/27709
Fixes: https://github.com/rust-lang/rust/issues/57558
- add `add Ipv4Addr::is_reserved()`
- [X] implementation
- [X] tests
- add `Ipv6Addr::is_unicast_link_local_strict()` and update `Ipv6Addr::is_unicast_link_local()` documentation
- [X] implementation
- [X] test
- add `Ipv4Addr::is_benchmarking()`
- [X] implementation
- [X] test
- add `Ipv4Addr::is_ietf_protocol_assignment()`
- [X] implementation
- [X] test
- add `Ipv4Addr::is_shared()`
- [X] implementation
- [x] test
- fix `Ipv4Addr:is_global()`
- [X] implementation
- [x] test
- [X] refactor the tests for IP properties. This makes the tests more verbose, but using macros have two advantages:
- it will now be easier to add tests for all the new methods
- we get clear error messages when a test is failing. For instance:
```
---- net::ip::tests::ip_properties stdout ----
thread '<unnamed>' panicked at 'assertion failed: !ip!("fec0::").is_global()', src/libstd/net/ip.rs:2036:9
```
Whereas previously it was something like
```
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
left: `true`,
right: `false`', libstd/net/ip.rs:1948:13
```
-----------------------
# Ongoing discussions:
## Should `Ipv4Addr::is_global()` return `true` or `false` for reserved addresses?
Reserved addresses are addresses that are matched by `Ipv4Addr::is_reserved()`.
@the8472 [pointed out](https://github.com/rust-lang/rust/pull/60145#issuecomment-485458319) that [RFC 4291](https://tools.ietf.org/html/rfc4291#section-2.4) says IPv6 reserved addresses should be considered global:
```
Future specifications may redefine one or more sub-ranges of the
Global Unicast space for other purposes, but unless and until that
happens, implementations must treat all addresses that do not start
with any of the above-listed prefixes as Global Unicast addresses.
```
We could extrapolate that this should also be the case for IPv4. However, it seems that [IANA considers them non global](https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml) (see [my comment](https://github.com/rust-lang/rust/pull/60145#issuecomment-485713270))
### Final decision
There seems to be a consensus that reserved addresses have a different meaning for IPv4 and IPv6 ([comment1](https://github.com/rust-lang/rust/pull/60145#issuecomment-485963789) [comment2](https://github.com/rust-lang/rust/pull/60145#issuecomment-485944582), so we can consider that RFC4291 does not apply to IPv4, and that reserved IPv4 addresses are _not_ global.
## Should `Ipv6Addr::is_unicast_site_local()` exist?
@pusateri [noted](https://github.com/rust-lang/rust/pull/60145#issuecomment-485507515) that site-local addresses have been deprecated for a while by [RFC 3879](https://tools.ietf.org/html/rfc3879) and new implementations _must not_ support them. However, since this method is stable, removing does not seem possible. This kind of situation is covered by the RFC which stated that existing implementation _may_ continue supporting site-local addresses.
### Final decision
Let's keep this method. It is stable already, and the RFC explicitly states that existing implementation may remain.
---------
Note: I'll be AFK from April 27th to May 11th. Anyone should feel free to pick this up if the PR hasn't been merged by then. Sorry for dragging that for so long already.
error: remove StringError from Debug output
Seeing `StringError("something something")` in debug output can cause
someone to think there was an error dealing with `String`s, not that the
error type is just a string. So, remove that noise.
For example:
```
io error: Custom { kind: InvalidData, error: StringError("corrupt data") }
```
With this change:
```
io error: Custom { kind: InvalidData, error: "corrupt data" }
```
Warn on bare_trait_objects by default
The `bare_trait_objects` lint is set to `warn` by default.
Most ui tests have been updated to use `dyn` to avoid creating noise in stderr files.
r? @Centril
cc #54910
Chris Gregory