Support no_std use cases by using alloc

[CryZe]

We long term want to support compilation of livesplit-core with just core + alloc. You'd provide your own time source as some global handler but other than that everything should mostly just work as we already see with wasm32-unknown-unknown. However most crates that we depend on probably don't support this yet, so that's probably going to be a lot of Pull Requests.

Update

All the crates we need are sufficiently patched on forked branches. We just need to do a bunch of PRs now. Here's the super fancy results, with LiveSplit One being rendered within the world of Wind Waker:

https://twitter.com/CryZe107/status/1158444993549414401

Status

Basic Support

Required

• base64 - Released as 0.11.0, PR is merged Implement Support for no_std marshallpierce/rust-base64#111
• derive_more - Released as 0.99.0, PR is "merged" Fix no_std support JelteF/derive_more#84
• odds
• ordered-float
• palette - Released as 0.5.0, PR is merged Fix no_std build failure Ogeon/palette#138
• serde
• snafu - Released as 0.6.0, PR is merged Implement Support for no_std shepmaster/snafu#138
• hashbrown - Released as 0.6.0 (There might be some bug though ahash still doesn't work on no_std for me tkaitchuck/aHash#17)
• libm

Polyfilled (not required, but would be good to get rid of the polyfill)

• unicase - Released as 2.6.0, PR is merged Implement no_std support seanmonstar/unicase#34
• indexmap - Released as 1.3.0, PR is merged Support building without libstd indexmap-rs/indexmap#106 (but serde support is missing serde feature is incompatible with no_std indexmap-rs/indexmap#109)
• chrono - Released as 0.4.10, PR is merged Implement Support for no_std chronotope/chrono#341

Optional

• byteorder - Some IO.
• image - Too much IO.
• livesplit-hotkey - We don't really need it, but we can easily provide an empty hotkey implementation.
• livesplit-title-abbreviations
• parking_lot - Not really needed on no_std, does too many OS things.
• quick-xml - Too much IO.
• serde_json - Too much IO, but there is a PR: No_std support serde-rs/json#516
• utf-8 - Uses IO.

Rendering

• euclid - Released as 0.20.6, PR is merged Implement actual support for no_std servo/euclid#372
  • num-traits - Released as 0.2.9, PR is merged Revive Float+Real in no_std thanks to libm rust-num/num-traits#99
• ttf-parser
• rustybuzz - PR is is merged, needs a release: Implement no_std support harfbuzz/rustybuzz#30
• lyon - Needs a PR: https://github.com/CryZe/lyon/tree/no-std
  • depends on euclid
  • sid - Released as 0.6.1, PR is merged Implement Support for no_std nical/sid#2
• rusttype - Released as 0.8.0, PR is merged https://gitlab.redox-os.org/redox-os/rusttype/merge_requests/145
  • stb_truetype - Released as 0.3.0, PR is merged https://gitlab.redox-os.org/redox-os/stb_truetype-rs/merge_requests/31
• smallvec - Released as 0.6.11, PR is merged alloc is now stable servo/rust-smallvec#159

Software Rendering

• tiny-skia - Needs a PR
• euc - Released as 0.5.0, PR is merged Implement proper no_std support zesterer/euc#12
  • vek - Released as 0.10.0, PR is merged Implement Support for no_std yoanlcq/vek#41
    • depends on num-traits

[CryZe]

It seems that std::io is causing massive problems, where all our parsing, saving, serializing and co. is just not within the bounds of core and alloc. It easily could be as there barely is a reason you can't do IO without an operating system, but it's currently std only due to OS specific error codes. There is a fork called core-io, but that's going to be a ton of PRs. However there is the possibility of simply not doing any parsing, saving and serializing on no_std until then. Other problems include HashMap, Hotkeys, timing and paths, but all of these can easily be replaced (BTreeMap, mocked Hotkeys, timing handler, and a wrapper around String / &str).

Images are probably also going to be problematic, but other than for rendering, image shrinking and parsing, we don't actually need to interpret them.

[hallcristobal]

Speaking in terms of a no_std implementation, I see no real reason to have file IO directly. At most I could see implementing support for Parsing and Serializing but leave it to the developer implementing the no_std library to handle any IO needs. This would require a custom built BufReader, BufRead, Seek (possibly others) implementations which might be outside the scope of this crate though. Having livesplit-core omit this functionality until that can be safely, and correctly, implemented seems like a viable path to go down for now.

[CryZe]

Well yeah it wouldn't be File IO, it would just be the IO traits, such as Read, Write, Seek, BufRead that we can't use as they are in std only. And all our dependencies use them too, so that's a pain to fix in the ecosystem without no clear solution other than possibly using the fork, but that's super hacky too.

[CryZe]

All required crates are released now, so we can merge basic support in.