#[no_std] support

[ExpHP]

Closes #147

The breaking changes are:

• A change in the signature of two functions (monoid::combine_all, semigroup::combine_all_option) may break type inference
• Adding default-enabled features std and validated may break client crates using default-features = false.

---

The toughest part is the tests. Several doctests were cfged out using the fact that doc comments are actually attributes.

It is crucial that frunk_derive does not depend on the std feature of frunk_core, or else we'd have to remove all usage of #[derive] from the doc tests in frunk_core. This is because it is impossible to disable features of frunk_core enabled by frunk_derive due to the circular dev-dependency. (features enabled by dev-dependencies are enabled in all builds, not just tests)

Thankfully, frunk_derive currently does not actually need to depend on frunk_core at all, so I removed the dependency.

[ExpHP]

Haven't looked at the failure yet, but the CI testing should be done differently

https://users.rust-lang.org/t/how-to-make-a-test-guarantee-that-a-crate-was-built-with-no-std/24964

[ExpHP]

I expanded the initial comment.

[TheVova]

Nice! I'll give this a test spin and look around to see if i can help fix some stuff as i find them :)

[ExpHP]

I just remembered that I forgot about this.

IIRC the most recently merged PR was incompatible with this, so it will need a quick rebase. We can start working towards a v0.3.0.

[ExpHP]

Oh, for crying out loud:

I am once again stumped how to make this work. The last frunk update added all this proc macro stuff which uses the proc-macro2 crate which does not appear to support #[no_std].

I think more specifically the issue is that we use proc-macro-hack, which requires the existence of a normal crate frunk_proc_macros that depends on proc-macro-hack, which depends on proc-macro2. Because frunk_proc_macros is not a proc-macro crate, cargo sees all of its dependencies as runtime dependencies of frunk. I think.

[ExpHP]

I'd like to merge this soon because basically every single intervening PR has broken it. This means the next version will have to be a major version bump.

[Centril]

@lloydmeta @ExpHP Btw I should note that my language & release team duties currently prevent me from devoting any time to this crate atm. So please don't feel the need to ask for my opinions. :) (I might have time in the future...)