officially support #![no_std] #41

[colin-kiegel]

cc @cramertj

This is work in progress and does not work yet.

open questions

• how do we tell cargo or travis that a certain test should only run on nightly rust? (#![feature(collections)] requires nightly)
• something strange happens with this code.

quote!(
    #[cfg(not(no_std))]
    #builder_vis fn build(#ref_self) -> ::std::result::Result<#struct_name #ty_generics, ::std::string::String> {
        /* ... */
    }
    #[cfg(no_std)]
    #builder_vis fn build(#ref_self) -> ::core::result::Result<#struct_name #ty_generics, ::collections::string::String> {
        /* ... */
    }
)

The expanded code only contains the first part

#[cfg(not(no_std))]
#builder_vis fn build(#ref_self) -> ::std::result::Result<#struct_name #ty_generics, ::std::string::String> {
    /* ... */
}

It's like the cfg-attributes always evaluate to #[cfg(not(no_std))]==true and #[cfg(no_std)]==false -- independently of the testcase. I would not be surprised if this was a rust or cargo bug evaluating the cfg-attribute in the wrong context - otherwise I don't understand it.

[colin-kiegel]

A workaround would be having an explicit #[builder(no_std)] attribute - but I feel like we should try to get the conditional compilation approach working.

Suggestions are welcome - I am kind of stuck right now. :-)

This is what I mean: cargo expand --test no_std

Where this is the original: tests/no_std.rs

And this is the code that should be emitted: src/lib.rs

PS: It's no different if I move the test to the examples folder.

[colin-kiegel]

Ok, I have now worked around the strange issues with emitting #[cfg(this)] ... #[cfg(that)] ... code.
The new approach requires to annotate the struct with #[builder(no_std)].

cc @killercup in case you want to give feedback. :-)

[colin-kiegel]

Oh, interesting - compiletest seems to not support #[no_std] that easily... Let's see.

[killercup]

Seems good, I have left one inline comment about String though.

[killercup]

This is the reason extern crate collections is required, right? Can we work around that? E.g., not give string error messages when using no_std but more simple ones?

[colin-kiegel]

Yep, I was thinking about that too.

I would say, that we could implement that as a separate feature. In fact this could just mean to provide more structured errors. I just opened issue #60 for that. How does that sound? :-)

[killercup]

👍