Apparently Cargo is applying these features to the non-dev dependency on
serde as well. Concluded by running `cargo clean && cargo build` and
observing that serde_derive was getting built.
Not sure what is going on with this failure that just started happening with no
code change on our end. Wait and see if it goes away.
On asmjs-unknown-emscripten:
Assertion failed: compiled without a main, but one is present. if you added
it from JS, use Module["onRuntimeInitialized"]
undefined:109
throw ex;
^
abort("Assertion failed: compiled without a main, but one is present. if you
added it from JS, use Module[\"onRuntimeInitialized\"]") at Error
On wasm32-unknown-emscripten:
Assertion failed: compiled without a main, but one is present. if you added
it from JS, use Module["onRuntimeInitialized"]
failed to asynchronously prepare wasm: abort("Assertion failed: compiled
without a main, but one is present. if you added it from JS, use
Module[\"onRuntimeInitialized\"]") at Error
This should prevent accidentally inserting something under one of these
cfgs that is available only on a newer rustc. For example if something
is changed in the Duration serialization, but that change works only on
a recent rustc, our test suite will not have caught it before.
* move to cargo clippy instead of using the clippy plugin
fixes#729
* non-exectable scripts must be run with `sh`
* don't build serde in the clippy travis job
* only run clippy tests if installing clippy succeeds
* why is travis so picky?
* no more serde_codegen
* serde_test_suite_deps has no features
* don't use empty loops, llvm optimizes them to undefined behaviour
* abort the clippy job when clippy lints are triggered
* use caches on travis to speed up builds
* why are we even using `travis-cargo`?
* need to reinstall clippy frequently due to nightly updates
* command line tools are hard
