error[E0152]: duplicate lang item in crate `std` (which `indexmap` depends on): `panic_impl`.

[tdelabro]

Hey,

I'm trying to use indexmap in a substrate pallet, which is a no_std environment.

If I import: indexmap = { version = "1.9.2", default-features = false }
I get the following error:

 error[E0152]: duplicate lang item in crate `std` (which `indexmap` depends on): `panic_impl`.
    |
    = note: the lang item is first defined in crate `sp_io` (which `frame_support` depends on)
    = note: first definition in `sp_io` loaded from /Users/tdelabro/Documents/code/starkware/kaioshin/target/debug/wbuild/kaioshin-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-c4656f0a7cd2540b.rmeta
    = note: second definition in `std` loaded from /Users/tdelabro/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libstd-d66a635e2d91bd07.rlib

  For more information about this error, try `rustc --explain E0152`.
  warning: `pallet-cairo-execution-engine` (lib) generated 1 warning
  error: could not compile `pallet-cairo-execution-engine` (lib) due to previous error; 1 warning emitted

Which usually indicate that some crate uses an std feature.

This import the following version:

[[package]]
name = "indexmap"
version = "1.9.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1885e79c1fc4b10f0e172c475f458b7f7b93061064d98c3293e98c5ba0c8b399"
dependencies = [
"autocfg",
"hashbrown 0.12.3",
"serde",
]

I can't find this commit on your repo so I have tried other versions of the crate: 4d410509d2e67c3d33e17c6d4cdbf622ea8458f8 and 4d52cf338c6ff9f742aac716f41b8a5497842f92, which are the two last commits on your indexmap-1.x release branch, both raise the same problem.

The strange thing is that any commit on the branch master, including ca5f848e10c31e80aeaad0720d14aa2f6dd6cfb1 which is the commit of the release 1.9.2 are valid and does not raise any errors.

My conclusion is that there is something wicked with your indexmap-1.x release branch.

A temporary fix is to use the master branch rather that the crate.io releases.

[cuviper]

The "wicked" thing is that we added no_std support after we had already released 1.0 as a std-only crate, so the usual --no-default-features method of avoiding std was not possible. That is, someone could have already been running no-default and expecting std-dependent methods to work. So instead, we added build-script detection for whether the target has a std crate at all, and the manual "std" feature only serves to skip that detection.

But this scheme doesn't work in your case, where you want to avoid std lang items even when the target does support it. Version 2.0 will solve this by only using an explicit "std" feature opt-in, not detection.

[tdelabro]

Okay, thank you for the explanations!
I will be using version 2.0-pre for now.
Best luck with your current work on this new version

[tdelabro]

Hello again @cuviper,

So I did what we said, using 2.0.0-pre for now but it causes a problem mentioned here: starkware-libs/cairo#3297 (comment)

What do you think we can do?
Could you publish a 2.0.0-pre to crates.io?
Could you just release 2.0.0 (or 1.10.0 if it's enough from a server point of view) where only the way no-std is supported changes? And keep the other breaking changes for later?
Are there other options to explore?

Btw, if the problem is the amount of work it requires, I would happily prepare a PR myself for you to review and publish

[tdelabro]

Thanks a lot @cuviper !