Impossible to build the `toml` crate for the `riscv32imc-unknown-none-elf ` target in `no_std`

[Luni-4]

It is not possible to build the toml crate for the riscv32imc-unknown-none-elf target in a no_std environment. The following error occurs when running the cargo build --release command:

error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> /home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/toml-0.9.8/src/de/error.rs:7:26
    |
  7 |     input: Option<alloc::sync::Arc<str>>,
    |                          ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:233:9
    |
232 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    |                                     ------------------------- the item is gated behind the `ptr` feature
233 | pub mod sync;
    |         ^^^^

error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> /home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/toml-0.9.8/src/de/error.rs:14:37
    |
 14 |     pub(crate) fn new(input: alloc::sync::Arc<str>, error: toml_parser::ParseError) -> Self {
    |                                     ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:233:9
    |
232 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    |                                     ------------------------- the item is gated behind the `ptr` feature
233 | pub mod sync;
    |         ^^^^

error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> /home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/toml-0.9.8/src/de/error.rs:205:26
    |
205 |     input: Option<alloc::sync::Arc<str>>,
    |                          ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:233:9
    |
232 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    |                                     ------------------------- the item is gated behind the `ptr` feature
233 | pub mod sync;
    |         ^^^^

error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> /home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/toml-0.9.8/src/de/error.rs:230:47
    |
230 |                 .get_or_insert_with(|| alloc::sync::Arc::from(self.source.input()));
    |                                               ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:233:9
    |
232 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    |                                     ------------------------- the item is gated behind the `ptr` feature
233 | pub mod sync;
    |         ^^^^

error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> /home/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/toml-0.9.8/src/de/error.rs:242:43
    |
242 |             .get_or_insert_with(|| alloc::sync::Arc::from(self.source.input()));
    |                                           ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:233:9
    |
232 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    |                                     ------------------------- the item is gated behind the `ptr` feature
233 | pub mod sync;

Is there any possible workaround? Thanks in advance!

The Cargo.toml with the salient parts:

[package]
edition = "2024"

[dependencies]
toml.version = "0.9.8"
toml.default-features = false
toml.features = ["display", "parse", "serde"]

The .cargo/config.toml

[env]
ESP_LOG="info"

[build]
rustflags = [
  # Required to obtain backtraces (e.g. when using the "esp-backtrace" crate.)
  # NOTE: May negatively impact performance of produced code
  "-C", "force-frame-pointers",
]

target = "riscv32imc-unknown-none-elf"

[unstable]
build-std = ["alloc", "core"]

The rust-toolchain.toml file

[toolchain]
channel = "nightly"
components = ["rust-src"]
targets = ["riscv32imc-unknown-none-elf"]

[epage]

Hmm,

Should we always create a String / Box<str>? There would be no performance difference for non-error recovery cases. For error recovery cases, it would be an allocation per error. Error paths will generally be light so maybe thats not too bad. There is a mode in Cargo where we parse a lot of TOML files and then throwaway most of the results (searching git dependencies for a package name) and in some of those cases, there can be errors.

We could make this conditionally compiled but not thrilled about mirroring that condition. Not thrilled with having to verify both code paths.

Either way, I'm not thrilled with what would be needed to ensure we don't regress this. Maybe it can be a best effort.

Before making a decision, going to wait to see if there is any input on this.

[pferreir]

Just bumped into this, on thumbv6m-none-eabi.

[Luni-4]

For error recovery cases, it would be an allocation per error. Error paths will generally be light so maybe thats not too bad. There is a mode in Cargo where we parse a lot of TOML files and then throwaway most of the results (searching git dependencies for a package name) and in some of those cases, there can be errors.

I’m not familiar with the internal implementation of toml-rs, so this is just a guess. Could the errors be divided into two categories: &'static str and String? That might help reduce allocations. Would using Cow make a difference?

[epage]

The string is not related to an error message but is a copy of the input itself to allow for annotating it in error messages, so &'static str wouldn't work.