Fixed: Build in no_std environment

[Sewer56]

This simple PR makes it possible to build the library in a no_std environment once again.

Although the library itself is no_std, it's being tested under an std environment; as a result of this, implicit use(s) that are automatically imported by std apply while building tests, but not while building from an actual no_std environment.

In this case, we needed to specify the imports from alloc manually.

[athre0z]

Ah yeah, good catch. I intended to initially make the encoder feature depend on the std feature, but it looks like I forgot to actually do that.

It's also good to know that our tests currently don't properly catch such cases. We should probably add a cargo test --no-default-features --features <all features that are supposed to work without std feature> run in the text matrix, but that doesn't have to happen in the scope of this PR (unless you feel like it).

IMO we shouldn't just require alloc to be present in no_std builds. We have two alternatives here:

• Disable the encode function returning a Vec if the std feature isn't enabled. Users can still use encode_into with a buffer that they allocated themselves (either with alloc crate or stack array). Rework tests to use encode_into or also just disable them in no-libc mode until we can be bothered to rework them. extern crate alloc not required.
• Add a separate alloc feature flag and make the encode(..) -> Vec<...> function + extern crate alloc depend on that.

Personally I don't have a strong opinion here. The second variant might be nicer in the long run, because it'd also allow using the formatter in no_std environments.

[Sewer56]

Did you also see my comment above? 😅

Yup, I saw the comment. Seems I just tabbed out for work stuff and forgot to come back.

---

Anyway, I think the second option is probably more preferable.

I feel like allowing the user to 'opt-into' functionality is preferable, compared to effectively locking them out (by asking for full std to get alloc)

Although I myself am not an embedded programmer,

I cannot really imagine a world where you'd be programming without any sort of allocator, even if it allocates in some memory block at the end (top) of the stack.

Assuming there are a bunch of no_std users who do have some form of alloc, it'd feel bad to exclude functionality they can still technically access without full std.

[athre0z]

Yup, I saw the comment. Seems I just tabbed out for work stuff and forgot to come back.

Cool, no pressure or hurry: it just seemed like you might have missed it since you immediately fixed the one thing and then went idle. :)

I cannot really imagine a world where you'd be programming without any sort of allocator, even if it allocates in some memory block at the end (top) of the stack.

So far I've managed to avoid need for a dynamic allocator in all my no-libc projects. But I agree with option 2 being preferable in general.

Assuming there are a bunch of no_std users who do have some form of alloc, it'd feel bad to exclude functionality they can still technically access without full std.

Yeah. The separate alloc feature is also what most other crates with no_std do, I think.

[athre0z]

Superseded by #37