Yup, can confirm. I don't know much rust but I'm not sure if the stack trace is any help at all. The only mint related lines seem to be around 13 and 14.

thread 'main' panicked at src/main.rs:87:61:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:     0x55ce46401c32 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hd067277452905fe3
   1:     0x55ce46425b83 - core::fmt::write::he8c54b1b75450954
   2:     0x55ce463fe763 - std::io::Write::write_fmt::h24912c1e401ba6d1
   3:     0x55ce46401a82 - std::sys::backtrace::BacktraceLock::print::hdf23e03df5369928
   4:     0x55ce46403072 - std::panicking::default_hook::{{closure}}::h410657f83c887868
   5:     0x55ce46402e75 - std::panicking::default_hook::h89d852edc127c4b8
   6:     0x55ce46403a92 - std::panicking::rust_panic_with_hook::hd12d0c7813293dad
   7:     0x55ce464037e6 - std::panicking::begin_panic_handler::{{closure}}::h0b9dd56a7f229e1a
   8:     0x55ce46402139 - std::sys::backtrace::__rust_end_short_backtrace::hfc673033d2b0cd00
   9:     0x55ce464034ad - __rustc[8c94f3b18780567b]::rust_begin_unwind
  10:     0x55ce46423600 - core::panicking::panic_fmt::h3e85405dee1a1369
  11:     0x55ce4642368c - core::panicking::panic::h865418c562774721
  12:     0x55ce46423579 - core::option::unwrap_failed::he503da1c147f7412
  13:     0x55ce45fdbcaa - <mint::Args as clap_builder::derive::Args>::augment_args::hc28a4b51847ac5ad
  14:     0x55ce45fd8d49 - mint::main::hb71a1ea25e39b453
  15:     0x55ce45fdcd63 - std::sys::backtrace::__rust_begin_short_backtrace::heb83d7f7ba2723a4
  16:     0x55ce45fd732d - std::rt::lang_start::{{closure}}::h1f89053be7f9c1f8
  17:     0x55ce463fa3a4 - std::rt::lang_start_internal::h71611c6ff65e6c36
  18:     0x55ce45fdc195 - main
  19:     0x7fd7da02a47e - __libc_start_call_main
  20:     0x7fd7da02a539 - __libc_start_main_impl
  21:     0x55ce45fd6425 - _start
  22:                0x0 - <unknown>

I also checked src/main.rs and the offending line seems to be the following:

87:#[command(author, version=mint_lib::built_info::GIT_VERSION.unwrap())]

It seems that mint_lib::built_info is importing the file built.rs which is supposed to write something somewhere. Maybe that is failing? I don't really know though. That's as far as I could get.

Edit 2: Okay, so I did a bit more digging and found out that the stuff I mentioned previously is not relevant at all. The problem seems to be in the built.rs file generated during build. Below are the relevant lines:

#[doc=r#"If the crate was compiled from within a git-repository, `GIT_VERSION` contains HEAD's tag. The short commit id is used if HEAD is not tagged."#]
#[allow(dead_code)]
pub static GIT_VERSION: Option<&str> = None;

The GIT_VERSION variable is being set to None here. This is what's causing the .unwrap() to fail.

I see what's happening here though. While nix copies .cargo and .github dirs as well as .gitignore to the build sandbox, it does not copy the .git dir, which is what identifies a dir as a git repo and is also what built seems to use for getting the build metadata (If the crate was compiled from within a git-repository).

I think a fallback version number in such cases where GIT_VERSION is None may help solve this issue.

panic on nixos #285

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions