tls_codec: use fully qualified name in derive macro

[imor]

Using #[derive(TlsSerialize)] on a struct forced the user to include std::format.

[franziskuskiefer]

Do you have a minimal example where this makes trouble? Generally this shouldn't be necessary.

[imor]

I was working in adding support for the Signed Certificate Timestamp extension in x509-cert in my branch and when I comment out this line the code doesn't compile. Specifically this #[derive(TlsSerialize)] fails to compile. If I apply the patch in this PR it works.

I also tried the same code in a fresh project where the #[derive(TlsSerialize)] does work without the explicit use statement. Not really sure what's going on.

[imor]

Just checked the output of cargo expand and it expands the format to ::alloc::fmt::format:

                  Err(
                        tls_codec::Error::EncodingError({
                            let res = ::alloc::fmt::format(
                                format_args!(
                                    "Expected to serialize {0} bytes but only {1} were generated.",
                                    expected_written, written
                                ),
                            );
                            res
                        }),
                    )

Not sure why that shouldn't be sufficient to compile the code.

[imor]

I think I got it. The crate x509-cert is marked #![no_std]. Which means there is no prelude and hence no format!. Looks like the tls_codec_derive crate always assumes that std will be available. It needs to be updated to support no_std as well.

[tarcieri]

@imor FWIW all of the X.509-related crates we have in this repo have a hard dependency on liballoc, so using alloc::fmt::format should be fine

[imor]

@tarcieri thanks that makes sense, I'll add a use alloc::format in my code.

The question about whether tls_codec_derive should refer to items in stdlib still remains. IMHO it should not unconditionally depend upon stdlib because it restricts the derive macros to be usable only in stdlib environments. If you guys agree I can open another issue to make tls_codec_derive no_std compatible.

I will also be closing this PR since no_std compatibility is more work than what is done in this PR.

[franziskuskiefer]

Yes, the derive crate currently requires std.
Making it no_std compatible would be nice but indeed a little more work.

[imor]

Closing this PR. A new issue for no_std support is added here