Add support for no_std environments

[YtvwlD]

In the past I've written a bootloader which uses TOML as the format for the configuration file format.

The UEFI targets (i686-unknown-uefi and x86_64-unknown-uefi) provide core and alloc (among others), but they currently don't provide full std support.

https://github.com/toml-rs/toml-rs/pull/391 and https://github.com/toml-rs/toml-rs/pull/429 added support for those environments for the old toml-rs crate (thought they were never merged). I'd be nice to have support here.

[epage]

From alex in those PRs

Thanks for the PR, but I'm personally not too thrilled to add no_std support like this. To me no_std means "only core", not "both core and alloc". This library gets pretty un-idiomatic pretty quickly (as shown here) if alloc enters the picture, and I do not want to maintain the alloc-specific code.

Thanks for the PR, but I personally do not want to maintain such support. If you have targets you're interested in building which are missing std then I'd recommend getting std to build for those targets instead.

I'm not too sure what all alex's concern was in maintaining no_std alloc support. I would prefer we wait on re-evaluating this until after #340 so we have a better idea of what the landscape will be (e.g. dependencies that need updating)

[YtvwlD]

So, do you have a better idea of the landscape now? :)

[epage]

We likely will never support core.

Stepping through this...

• We would likely want to copy what winnow does which simplifies some of the code.
• I think we could add the std feature without a breaking change as std wouldn't have anything exclusive to it and the types are the same so someone should get the same behavior if they upgrade with default-features = false
• It might be some work making sure this is all propagated from our dependencies to toml_edit to toml.
• We might want to adopt cargo hack to help us in verifying this

My main remaining concern is any of the maintenance pain in dealing with this. With winnow, which makes a lot more sense in core/alloc use cases, its been easy to mess up and use std types on accident and not find it for a bit (granted, I've not adopted cargo hack there)

[theaddonn]

I think this is really needed