The docs imply that the only consideration for using the
serde_if_integer128 macro is support for older versions of Rust, but
Serde's build configuration for 128-bit integers is also gated on the
target platform. For example, if Serde is being compiled for an
emscripten target, then it will not provide 128-bit integer APIs.
See also: https://github.com/BurntSushi/rust-csv/issues/158
warning: the feature `alloc` has been stable since 1.36.0 and no longer requires an attribute to enable
--> serde/src/lib.rs:84:40
|
84 | #![cfg_attr(feature = "alloc", feature(alloc))]
| ^^^^^
|
= note: #[warn(stable_features)] on by default
These hit a strange error in our Emscripten builder in Travis as well as
locally through cargo web:
ERROR: failed to execute cargo: Resource temporarily unavailable (os error 11)
Without this:
error: failed to select a version for `serde_test_suite`.
... required by package `serde_test_suite-tests v0.0.0`
versions that meet the requirements `= 0.0.0` are: 0.0.0
the package `serde_test_suite-tests` depends on `serde_test_suite`, with features: `serde` but `serde_test_suite` does not have these features.
failed to select a version for `serde_test_suite` which could resolve this conflict
Seems like a Cargo bug -- I will minimize and report.
The nightly compiler just added a dependency on serde so libserde ends
up in the sysroot, breaking crate resolution inside of compiletest. We
will need to figure out how else to run these tests.
error[E0464]: multiple matching crates for `serde`
--> $DIR/wrong_ser.rs:9:10
|
9 | #[derive(Serialize)]
| ^^^^^^^^^
|
= note: candidates:
crate `serde`: /rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libserde-2b75907288aa7c40.rlib
crate `serde`: /serde/test_suite/deps/target/debug/deps/libserde-33e0a319242344ce.rlib
