Remove the `NonMatchesExplode` variant now that no deriving impl uses it.
Removed `EnumNonMatching` entirely.
Remove now irrelevant `on_matching` field and `HandleNonMatchingEnums` type.
Removed unused `EnumNonMatchFunc` type def.
Drive-by: revise `EnumNonMatchCollapsedFunc` doc.
Made all calls to `expand_enum_method_body` go directly to
`build_enum_match_tuple`.
Alpha-rename `enum_nonmatch_g` back to `enum_nonmatch_f` to reduce overall diff noise.
Inline sole call of `some_ordering_const`.
Inline sole call of `ordering_const`.
Removed a bunch of code that became dead after the above changes.
In particular, I want authors of deriving modes to understand what
they are opting into (namely quadratic code size or worse) when they
select NonMatchesExplode.
closes#13367
[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,
```
trait Tr for Sized? {}
fn foo<Sized? X: Share>(x: X) {}
```
One of the long-term goals of the libstd facade is to move the collections
library underneath the standard library. This would imply that libcollections
today would invert its dependency with libstd.
One of the primary blockers for doing this is the HashMap collection. Of its two
major dependencies, hashing and randomness, this commit is the first step in
dealing with hashing.
When moving the hash module beneath libstd, it must break its primary dependence
on the io::Writer trait (used as the hashing state). The proposed strategy for
breaking this dependence is taking a similar path as core::fmt, which is to have
the hash module define its own "writer trait". This trait would be similar to
std::io::Writer, except that it would not return errors and it would have fewer
convenience methods.
The Hash trait today has its type parameter behind a feature gate (default type
parameters), so this pending change will likely break no code which hasn't opted
in to the feature gate. The SipState struct will lose its implementation of
io::Writer, but it will regain similar methods for dealing with writing data.
This change specifically prepares for the hash migration by modifying
deriving(Hash) to use the std:#️⃣:Writer bound instead of the std::io::Writer
bound. This bound is currently wired to std::io::Writer, but after a snapshot it
will have no need to be wired to the io writer trait.
This alters the borrow checker's requirements on invoking closures from
requiring an immutable borrow to requiring a unique immutable borrow. This means
that it is illegal to invoke a closure through a `&` pointer because there is no
guarantee that is not aliased. This does not mean that a closure is required to
be in a mutable location, but rather a location which can be proven to be
unique (often through a mutable pointer).
For example, the following code is unsound and is no longer allowed:
type Fn<'a> = ||:'a;
fn call(f: |Fn|) {
f(|| {
f(|| {})
});
}
fn main() {
call(|a| {
a();
});
}
There is no replacement for this pattern. For all closures which are stored in
structures, it was previously allowed to invoke the closure through `&self` but
it now requires invocation through `&mut self`.
The standard library has a good number of violations of this new rule, but the
fixes will be separated into multiple breaking change commits.
Closes#12224
If #[feature(default_type_parameters)] is enabled for a crate, then
deriving(Hash) will expand with Hash<W: Writer> instead of Hash<SipState> so
more hash algorithms can be used.
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.
Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.
This does not yet replace the old IterBytes-hash with this new
version.
