Where possible replace ::std with ::core in codegen

[dimpolo]

Partly resolves #72.

::alloc is more problematic since it requires a extern crate alloc;

[KodrAus]

We could add a alloc feature that's enabled by default that brings in the alloc crate so that we can use smart pointers like Arc and Box. If the alloc feature isn't enabled then we can support just & and &mut.

I actually don't think we have any need for full std in this crate!

[dimpolo]

How would you bring in the alloc crate?
One could split the crate into a proc-macro crate and one that re-exports alloc::boxed::Box, etc.
Then you could use something like ::auto_impl::Box in the generated code.

[KodrAus]

@dimpolo I think we might need to start wrapping the code we generate in a const so that we can extern crate in there, and determine within the macro (rather than the generated code) whether the path we're after comes from std or alloc.

So given an input like:

#[auto_impl(Arc)]
pub trait Trait {}

with the alloc feature instead of std, we might generate code that looks like:

pub trait Trait {}
const __AUTO_IMPL_TRAIT: () = {
    extern crate core;
    extern crate alloc;

    impl<T> Trait for alloc::sync::Arc<T> where T: Trait {}
};

We can look at that independently though unless you're keen to give it a go 🙂

[dimpolo]

Very keen in fact 😁
Luckily extern crate core; is not required.
Let me know if this is what you had in mind and if I should also fix the UI tests.

[LukasKalbertodt]

Sorry for taking so long to respond to this.

This seems like a useful change to me! Only thing I'm not yet sure about is whether we can release this as a minor version update. What if users have core or alloc somewhere in their root namespace (i.e. a module or a renamed crate?). Would that interfere?

I would also like to see some tests. Something that runs on CI which makes sure

• This crate works with a no_std environment: one with alloc and one without.
• That modules or crate renames don't interfere with our paths.

Could you still add those tests? That would be great! If you need any help or have questions about that, we can just discuss it here.

Oh and, I just fixed the UI tests in #74, so you can just rebase now.

[dimpolo]

Thanks for looking into this.

I'm not 100% sure but it seems as though things "just work".
Paths are correct and alloc doesn't need any special treatment.
A no_std library can use alloc freely and a binary would need to declare a #[global_allocator] first.

I believe a minor version update would be ok.

[KodrAus]

Is the idea of including these at the root here just to make sure we don't accidentally use module instead of crate paths to the standard library crates?

[dimpolo]

yep, that was the idea

[rakita]

It would be great if this can be merged, the change worked for my project.

[LukasKalbertodt]

Sorry for the terribly slow response. This looks good to me! Only thing I noticed: const _ requires Rust 1.37. In our README, we say that auto impl requires Rust 1.30, so this PR will bump the MSRV, so I will release this with a major version bump, i.e. 0.5.0. But I don't think it's a problem. Rust 1.37 is fairly old.

[LukasKalbertodt]

Released as 0.5.0.