This commit enables writing a stable implementation of the `Hasher` trait as
well as actually calculating the hash of a vlaue in a stable fashion. The
signature is stabilized as-is.
PR #23104 moved `is_null` and `offset` to an inherent impl on the raw pointer type.
I'm not sure whether or how it's possible to link to docs for that impl.
r? @steveklabnik
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
r? @Gankro
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
This trait has proven quite useful when defining marker traits to avoid the
semi-confusing `PhantomFn` trait and it looks like it will continue to be a
useful tool for defining these traits.
Previously, impls for `[T; n]` were collected in the same place as impls for `[T]` and `&[T]`. This splits them out into their own primitive page in both core and std.
Linking `__pthread_get_minstack`, even weakly, was causing Debian’s `dpkg-shlibdeps` to detect an unnecessarily strict versioned dependency on libc6.
Closes#23628.
For the rust-call ABI, the last function argument is a tuple that gets
untupled for the actual call. For bare functions using this ABI, the
code has access to the tuple, so we need to tuple the arguments again.
But closures can't actually access the tuple. Their arguments map to the
elements in the tuple. So what we currently do is to tuple the arguments
and then immediately untuple them again, which is pretty useless and we
can just omit it.
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro