built may panic when run in no-std environments

[ryan-summers]

For no-std targets that use built (i.e. /~https://github.com/quartiq/booster), the CARGO_CFG_TARGET_FAMILY environment variable may not be set by cargo. This is causing built v0.7.0 to fail to build due to a key error:

$ cargo build
   Compiling booster v0.5.0 (C:\Users\rsummers\Documents\repositories\quartiq\booster)
error: failed to run custom build command for `booster v0.5.0 (C:\Users\rsummers\Documents\repositories\quartiq\booster)`

Caused by:
  process didn't exit successfully: `C:\Users\rsummers\Documents\repositories\quartiq\booster\target\debug\build\booster-b9aa108a369761c8\build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'no entry found for key', C:\Users\rsummers\.cargo\registry\src\index.crates.io-6f17d22bba15001f\built-0.7.0\src\environment.rs:207:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think this variable should be treated as an Option instead. This was never an issue in v0.6.1

[lukaslueg]

Thanks for the heads-up. I'm not overly familiar with no-std-environment. To make this reproducible: The main crate is #![no_std], it's build.rs calls built? Also, when you say "never a problem with 0.7", I assume that to be a typo of "... 0.6"?!

[ryan-summers]

To make this reproducible: The main crate is `#![no_std]

Yeah, you can reference Booster's repo, where the main.rs is #![no_std]:
/~https://github.com/quartiq/booster/blob/2b353e0f377014d6feff6007a447e511eb135c9c/src/main.rs#L2

it's build.rs calls built?

Yep, very standard built usage as outlined in the docs:
/~https://github.com/quartiq/booster/blob/dependabot/cargo/built-0.7.0/build.rs

Also, when you say "never a problem with 0.7", I assume that to be a typo of "... 0.6"?!

Correct, sorry I meant to say 0.6.1

[ryan-summers]

Printing out all of the env vars during the build proicess yields the following:

$ cargo build 2>&1 | grep CARGO
  CARGO: \\?\C:\Users\rsummers\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe
  CARGO_CFG_PANIC: abort
  CARGO_CFG_TARGET_ARCH: arm
  CARGO_CFG_TARGET_ENDIAN: little
  CARGO_CFG_TARGET_ENV:
  CARGO_CFG_TARGET_HAS_ATOMIC: 16,32,8,ptr
  CARGO_CFG_TARGET_OS: none
  CARGO_CFG_TARGET_POINTER_WIDTH: 32
  CARGO_CFG_TARGET_VENDOR: unknown
  CARGO_ENCODED_RUSTFLAGS: -Clink-arg=-Tlink.x
  CARGO_HOME: C:\Users\rsummers\.cargo
  CARGO_MAKEFLAGS: -j --jobserver-fds=__rust_jobserver_semaphore_3180306332 --jobserver-auth=__rust_jobserver_semaphore_3180306332
  CARGO_MANIFEST_DIR: C:\Users\rsummers\Documents\repositories\quartiq\booster
  CARGO_PKG_AUTHORS: Ryan Summers <ryan.summers@vertigo-designs.com>:Robert Jördens <rj@quartiq.de>
  CARGO_PKG_DESCRIPTION: Firmware for the Sinara Booster device (STM32F4, Ethernet, RF power amplifiers)
  CARGO_PKG_HOMEPAGE:
  CARGO_PKG_LICENSE: MIT OR Apache-2.0
  CARGO_PKG_LICENSE_FILE:
  CARGO_PKG_NAME: booster
  CARGO_PKG_README: README.md
  CARGO_PKG_REPOSITORY: /~https://github.com/quartiq/booster
  CARGO_PKG_RUST_VERSION: 1.72
  CARGO_PKG_VERSION: 0.5.0
  CARGO_PKG_VERSION_MAJOR: 0
  CARGO_PKG_VERSION_MINOR: 5
  CARGO_PKG_VERSION_PATCH: 0
  CARGO_PKG_VERSION_PRE:

Based on this, it looks like CARGO_CFG_TARGET_FAMILY is indeed not present in the environment, hence the issue. This was surprising to me as the cargo docs indicate this should always be present (although it definitely doesn't make sense for a no-std platform).

[lukaslueg]

This is indeed a simple bug in built-0.7, which changed from effectively unwrap_or_default()- to unwrap-behavior. I'll fix that with a minor bump for 0.7, but I'd like for Upstream Gods to comment on what the correct behavior should be first.

[ryan-summers]

Thanks! I was thinking myself of opening an issue in cargo to ask about the environment variable because I was equally confused when reading the docs. No rush on my end, I just wanted to give you a heads up. :)

[lukaslueg]

@ryan-summers latest git should work for you again?! Upstream seems to remain unresolved wrt what the correct behavior actually is.

[ryan-summers]

The latest git hash indeed works now, thanks! :)

[lukaslueg]

@ryan-summers Thanks for checking, bumped to 0.7.1.