feature std leaking when using macro in no_std env

[koushiro]

In PR #35, data-encoding = { version = "2.3", default-features = false, features = ["alloc"] } was added into lib/macro/Cargo.toml and lib/macro/internal/Cargo.toml. It's ok for me.
But in the later commit 76e21dd, default-features = false, features = ["alloc"] was removed from lib/macro/internal/Cargo.toml, which cause the feature std of data-encoding leaking, I think.

Solution:

lib/macro/internal/Cargo.toml

[package]
name = "data-encoding-macro-internal"
version = "0.1.9"
authors = ["Julien Cretin <cretin@google.com>"]
license = "MIT"
edition = "2018"
description = "Internal library for data-encoding-macro"
readme = "README.md"
repository = "https://github.com/ia0/data-encoding"
include = ["Cargo.toml", "LICENSE", "README.md", "src/lib.rs"]

[lib]
proc-macro = true

[dependencies]
- data-encoding = { version = "2.3", path = "../.." }
+ data-encoding = { version = "2.3", path = "../..", default-features = false, features = ['alloc'] }
syn = "1"

BTW, we could add resolver = "2" to the Cargo.toml of downstream crate (only useful for rust 1.51+) to fix the issue (Cargo's New Feature Resolver), but we need to compile data-encoding twice.

[ia0]

Hi @koushiro

Thanks for the report!

As I see it, there are 2 problems:

1. The fact that std may leak from data-encoding-macro-internal to data-encoding-macro. The recommended solution for that is to use the new resolver as described in the README. I actually forgot to publish it when I updated it. It's done now. Thanks for bringing that up!
2. The data-encoding crate is built multiple times when using macros in no-std environments. I don't think this is fixable. There is one build with std for proc-macro and one build without. Note that there are only 2 builds when using alloc (and not 3). This is due to feature unification where the macro lib will use the alloc build instead of asking for a no-alloc build.

Does this clarify the situation?

[koushiro]

@ia0 Thanks for your reply.

Is there a solution for earlier rust versions?

[ia0]

Yes, it's in the README too. I don't know the earliest version where it would work, but it's at least a year (tracking issue).

[koushiro]

But it's doesn't work for earlier stable rust version, target thumbv6m-none-eabi.

you could try to run the below command under data-encoding/lib/macro directory:

cargo build --no-default-features --target thumbv6m-none-eabi

the target thumbv6m-none-eabi don't support libstd (only support liballoc and libcore), it's a good environment for no_std checking.

[ia0]

I'll look into this this week-end because it'll take some time. I want to do some experiments to see if there is a regression or if this is more of a feature request.

[ia0]

I could take a deeper look. I finally agree with your original post. Let me restate it with my own words:

• After a89028b and before 76e21dd, it was possible to use the macro library with the alloc feature with stable compilers.
• After 76e21dd, this was accidentally reverted in some refactoring.
• This doesn't matter for compilers 1.51 and later, but it does for compilers 1.50 and earlier.
• This can be fixed by using alloc feature in the macro internal proc-macro crate.
• This means that for old stable compilers, only the alloc and std features can be used (currently only std is possible because of the bug). For newer compilers (stable and nightly) using the new resolver, the no-alloc feature can also be used.

However, note that it's still not clear to me how a project may use the alloc feature with a stable compiler. I have problems with #[alloc_error_handler].

[ia0]

I've published data-encoding-macro=0.1.12 (and data-encoding-macro-internal=0.1.10) which should fix your issue. Thanks again for reporting the regression!