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
Print PermissionExt::mode() in octal in Documentation Examples
Printing the file permission mode on unix systems in decimal feels unintuitive. Printing it in octal gives the expected form of e.g. `664`.
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
Revert "Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators."
This changed observable behavior for several iterator types.
r? @alexcrichton
