This commit moves the libserialize crate (and will force the hand of the
rustc-serialize crate) to not require the `old_orphan_check` feature gate as
well as using associated types wherever possible. Concretely, the following
changes were made:
* The error type of `Encoder` and `Decoder` is now an associated type, meaning
that these traits have no type parameters.
* The `Encoder` and `Decoder` type parameters on the `Encodable` and `Decodable`
traits have moved to the corresponding method of the trait. This movement
alleviates the dependency on `old_orphan_check` but implies that
implementations can no longer be specialized for the type of encoder/decoder
being implemented.
Due to the trait definitions changing, this is a:
[breaking-change]
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.
All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.
To migrate all crates, add the following to your `Cargo.toml`:
[dependencies]
rustc-serialize = "0.1.1"
And then add the following to your crate root:
extern crate "rustc-serialize" as rustc_serialize;
Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.
[breaking-change]
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.
All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.
To migrate all crates, add the following to your `Cargo.toml`:
[dependencies]
rustc-serialize = "0.1.1"
And then add the following to your crate root:
extern crate "rustc-serialize" as rustc_serialize;
Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.
[breaking-change]
The examples in the documentation for syntax::ext::deriving::encodable
are outdated, and do not work. To fix this, the following changes are
applied:
- emit_field() -> emit_struct_field()
- read_field() -> read_struct_field()
- Use Result to report errors
- Add the mut keyword to Encoder/Decoder
- Prefer Encodable::encode() to emit_uint
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) {}
```
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
The most significant fix is for `syntax::ext::deriving::encodable`,
where one of the blocks of code, auspiciously containing `<S>` (recall
that Markdown allows arbitrary HTML to be contained inside it), was not
formatted as a code block, with a fun but messy effect.
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
@huonw
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
