force proc-macro to be no_std compatable

[mriise]

Setting the no_std attribute prevents std from leaking into the proc macro... for reasons I am unaware of, but it works (at least while building with thumbv6m-none-eabi as the target).

I was hoping to make an alloc feature for macro and macro-internal using the pattern I saw already being used in this library, but I couldn't get it to work.

no_std for this macro means multiformats/rust-multibase#25 can move ahead without lazy_static (and spin locks).

As a side note, proc-macro-hack isn't needed as a default as the proc-macro crate is stable.

[coveralls]

Coverage remained the same at 95.102% when pulling b492d58 on mriise:no_std_macro into 848efe3 on ia0:master.

[ia0]

Thanks a lot for the pull-request! I wanted to look into making the macro crate no-std too but was blocked by rust-lang/cargo#7915 more or less which is now solved apparently. And I didn't put effort because I wasn't sure it was needed. So this is good to know that some projects need the macro crate to be no-std. I'll take a look at your PR tonight (Europe time) or tomorrow. Thanks again!

[ia0]

Thanks! This looks good to me. It doesn't seem to break existing use-cases and adds support for using the macro crate in no-std environments that have an allocator. I created 2 actions items for me to follow-up on this (#36 and #37).

Do you need a release for those 2 crates (macro + macro-internal)?

[mriise]

Take your time to make the improvements, as no_std is more of an optional feature for multibase, there is no particular rush (unless someone opens an issue otherwise).

Thank you for the quick turn around on this!

[ia0]

It turned out to be simpler than expected. I released the macro crate at version 0.1.9.

[ia0]

Note that you may need the following in your .cargo/config.toml:

[unstable]
features = ["host_dep"]