2013-03-19 12:52:10 +00:00
|
|
|
// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT
|
2012-12-04 00:48:01 +00:00
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-12-31 04:25:18 +00:00
|
|
|
//! The compiler code necessary to implement the `#[derive]` extensions.
|
2014-11-26 02:17:11 +00:00
|
|
|
//!
|
|
|
|
//! FIXME (#2810): hygiene. Search for "__" strings (in other files too). We also assume "extra" is
|
|
|
|
//! the standard library, and "std" is the core library.
|
2012-11-20 02:05:50 +00:00
|
|
|
|
2014-02-05 14:08:17 +00:00
|
|
|
use ast::{Item, MetaItem, MetaList, MetaNameValue, MetaWord};
|
2013-05-17 11:27:17 +00:00
|
|
|
use ext::base::ExtCtxt;
|
2013-08-31 16:13:04 +00:00
|
|
|
use codemap::Span;
|
2014-09-13 16:06:01 +00:00
|
|
|
use ptr::P;
|
2014-05-16 07:16:13 +00:00
|
|
|
|
2014-09-07 20:58:41 +00:00
|
|
|
macro_rules! pathvec {
|
|
|
|
($($x:ident)::+) => (
|
|
|
|
vec![ $( stringify!($x) ),+ ]
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
macro_rules! path {
|
|
|
|
($($x:tt)*) => (
|
|
|
|
::ext::deriving::generic::ty::Path::new( pathvec!( $($x)* ) )
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
2014-04-30 09:26:50 +00:00
|
|
|
pub mod bounds;
|
2013-03-28 10:50:10 +00:00
|
|
|
pub mod clone;
|
2013-04-10 23:31:51 +00:00
|
|
|
pub mod encodable;
|
2013-04-09 01:53:39 +00:00
|
|
|
pub mod decodable;
|
2014-02-22 05:33:23 +00:00
|
|
|
pub mod hash;
|
2013-05-06 15:30:42 +00:00
|
|
|
pub mod rand;
|
2014-02-06 12:02:28 +00:00
|
|
|
pub mod show;
|
2013-09-12 04:51:13 +00:00
|
|
|
pub mod default;
|
2013-09-17 04:12:18 +00:00
|
|
|
pub mod primitive;
|
2012-11-20 02:05:50 +00:00
|
|
|
|
2013-03-30 14:58:05 +00:00
|
|
|
#[path="cmp/eq.rs"]
|
|
|
|
pub mod eq;
|
|
|
|
#[path="cmp/totaleq.rs"]
|
|
|
|
pub mod totaleq;
|
|
|
|
#[path="cmp/ord.rs"]
|
|
|
|
pub mod ord;
|
|
|
|
#[path="cmp/totalord.rs"]
|
|
|
|
pub mod totalord;
|
|
|
|
|
|
|
|
|
2013-03-28 10:50:10 +00:00
|
|
|
pub mod generic;
|
|
|
|
|
2015-01-24 23:28:58 +00:00
|
|
|
pub fn expand_deprecated_deriving(cx: &mut ExtCtxt,
|
|
|
|
span: Span,
|
|
|
|
_: &MetaItem,
|
|
|
|
_: &Item,
|
|
|
|
_: Box<FnMut(P<Item>)>) {
|
|
|
|
cx.span_err(span, "`deriving` has been renamed to `derive`");
|
|
|
|
}
|
|
|
|
|
2014-12-31 04:25:18 +00:00
|
|
|
pub fn expand_meta_derive(cx: &mut ExtCtxt,
|
|
|
|
_span: Span,
|
|
|
|
mitem: &MetaItem,
|
|
|
|
item: &Item,
|
|
|
|
mut push: Box<FnMut(P<Item>)>) {
|
2013-03-11 20:47:23 +00:00
|
|
|
match mitem.node {
|
2013-07-19 11:51:37 +00:00
|
|
|
MetaNameValue(_, ref l) => {
|
2014-12-31 04:25:18 +00:00
|
|
|
cx.span_err(l.span, "unexpected value in `derive`");
|
2013-03-11 20:47:23 +00:00
|
|
|
}
|
2014-02-13 17:46:46 +00:00
|
|
|
MetaWord(_) => {
|
2014-12-31 04:25:18 +00:00
|
|
|
cx.span_warn(mitem.span, "empty trait list in `derive`");
|
2014-02-13 17:46:46 +00:00
|
|
|
}
|
|
|
|
MetaList(_, ref titems) if titems.len() == 0 => {
|
2014-12-31 04:25:18 +00:00
|
|
|
cx.span_warn(mitem.span, "empty trait list in `derive`");
|
2013-03-11 20:47:23 +00:00
|
|
|
}
|
2013-07-19 11:51:37 +00:00
|
|
|
MetaList(_, ref titems) => {
|
2014-09-13 16:06:01 +00:00
|
|
|
for titem in titems.iter().rev() {
|
2013-03-11 20:47:23 +00:00
|
|
|
match titem.node {
|
2014-01-08 18:35:15 +00:00
|
|
|
MetaNameValue(ref tname, _) |
|
|
|
|
MetaList(ref tname, _) |
|
|
|
|
MetaWord(ref tname) => {
|
2015-01-02 22:44:21 +00:00
|
|
|
macro_rules! expand {
|
|
|
|
($func:path) => ($func(cx, titem.span, &**titem, item,
|
2015-01-06 17:24:46 +00:00
|
|
|
|i| push(i)))
|
2015-01-02 22:44:21 +00:00
|
|
|
}
|
|
|
|
|
2015-02-03 22:31:06 +00:00
|
|
|
match &tname[] {
|
2013-06-12 17:02:55 +00:00
|
|
|
"Clone" => expand!(clone::expand_deriving_clone),
|
2013-05-06 15:23:51 +00:00
|
|
|
|
2014-02-22 05:33:23 +00:00
|
|
|
"Hash" => expand!(hash::expand_deriving_hash),
|
2013-05-06 15:23:51 +00:00
|
|
|
|
rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-11 20:16:30 +00:00
|
|
|
"RustcEncodable" => {
|
2014-12-19 06:52:48 +00:00
|
|
|
expand!(encodable::expand_deriving_rustc_encodable)
|
rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-11 20:16:30 +00:00
|
|
|
}
|
|
|
|
"RustcDecodable" => {
|
2014-12-19 06:52:48 +00:00
|
|
|
expand!(decodable::expand_deriving_rustc_decodable)
|
rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-11 20:16:30 +00:00
|
|
|
}
|
|
|
|
"Encodable" => {
|
2014-12-19 06:52:48 +00:00
|
|
|
cx.span_warn(titem.span,
|
2014-12-31 04:25:18 +00:00
|
|
|
"derive(Encodable) is deprecated \
|
|
|
|
in favor of derive(RustcEncodable)");
|
rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-11 20:16:30 +00:00
|
|
|
|
|
|
|
expand!(encodable::expand_deriving_encodable)
|
|
|
|
}
|
2014-12-17 19:26:52 +00:00
|
|
|
"Decodable" => {
|
2014-12-19 06:52:48 +00:00
|
|
|
cx.span_warn(titem.span,
|
2014-12-31 04:25:18 +00:00
|
|
|
"derive(Decodable) is deprecated \
|
|
|
|
in favor of derive(RustcDecodable)");
|
rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-11 20:16:30 +00:00
|
|
|
|
|
|
|
expand!(decodable::expand_deriving_decodable)
|
|
|
|
}
|
2013-05-06 15:23:51 +00:00
|
|
|
|
2014-05-30 00:45:07 +00:00
|
|
|
"PartialEq" => expand!(eq::expand_deriving_eq),
|
2014-05-31 17:43:52 +00:00
|
|
|
"Eq" => expand!(totaleq::expand_deriving_totaleq),
|
2014-05-30 00:45:07 +00:00
|
|
|
"PartialOrd" => expand!(ord::expand_deriving_ord),
|
2014-05-31 17:43:52 +00:00
|
|
|
"Ord" => expand!(totalord::expand_deriving_totalord),
|
2013-05-06 15:23:51 +00:00
|
|
|
|
2013-06-12 17:02:55 +00:00
|
|
|
"Rand" => expand!(rand::expand_deriving_rand),
|
2013-05-06 15:30:42 +00:00
|
|
|
|
2015-01-28 17:43:16 +00:00
|
|
|
"Show" => {
|
|
|
|
cx.span_warn(titem.span,
|
|
|
|
"derive(Show) is deprecated \
|
|
|
|
in favor of derive(Debug)");
|
|
|
|
|
|
|
|
expand!(show::expand_deriving_show)
|
|
|
|
},
|
|
|
|
|
2015-01-20 23:45:07 +00:00
|
|
|
"Debug" => expand!(show::expand_deriving_show),
|
2013-09-17 04:12:18 +00:00
|
|
|
|
2013-09-12 04:51:13 +00:00
|
|
|
"Default" => expand!(default::expand_deriving_default),
|
2013-05-06 15:30:42 +00:00
|
|
|
|
2013-09-17 04:12:18 +00:00
|
|
|
"FromPrimitive" => expand!(primitive::expand_deriving_from_primitive),
|
|
|
|
|
2014-04-30 09:26:50 +00:00
|
|
|
"Send" => expand!(bounds::expand_deriving_bound),
|
2014-08-05 23:40:04 +00:00
|
|
|
"Sync" => expand!(bounds::expand_deriving_bound),
|
2014-04-30 09:26:50 +00:00
|
|
|
"Copy" => expand!(bounds::expand_deriving_bound),
|
|
|
|
|
2013-05-12 04:25:31 +00:00
|
|
|
ref tname => {
|
2014-05-16 17:45:16 +00:00
|
|
|
cx.span_err(titem.span,
|
2015-01-07 16:58:31 +00:00
|
|
|
&format!("unknown `derive` \
|
2014-05-16 17:45:16 +00:00
|
|
|
trait: `{}`",
|
2015-01-07 16:58:31 +00:00
|
|
|
*tname)[]);
|
2013-03-11 20:47:23 +00:00
|
|
|
}
|
2014-02-13 07:53:52 +00:00
|
|
|
};
|
2013-03-11 20:47:23 +00:00
|
|
|
}
|
|
|
|
}
|
2014-02-13 07:53:52 +00:00
|
|
|
}
|
2013-03-11 20:47:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|