i can think of two options:

1. bug the maintainer to make a new release that fixes the crates.io lockfile (crates.io allows git dependencies in dev-dependencies)
2. something else

i guess checking in cargo.lock isn't that uncommon:

$ fd 'Cargo\.lock' | wc -l
110

i guess checking in cargo.lock isn't that uncommon:

$ fd '^Cargo\.lock$' | wc -l
97

There used to be a lot more but I removed most of them... Anyways:

In this case I think it is fine to eat the bullet if the lockfile is not crazy large.

But in case you really don't want to:

• Fetch the lockfile from crates-io into your local git checkout, (you may need to remove it from .gitignore first)
• git add it,
• run any cargo command that tries to generate the lockfile (e.g. cargo build)
• generate a patch file via git diff
• in nixpkgs add the patch file to cargoPatches
• profit?

At least I think this could work.
You might be better off vendoring the lockfile.

There used to be a lot more but I removed most of them... Anyways:

In this case I think it is fine to eat the bullet if the lockfile is not crazy large.

But in case you really don't want to:

• Fetch the outdated lockfile from crates-io into your local git checkout, (you may need to remove it from .gitignore first)
• git add it,
• run any cargo command that tries to generate the lockfile (e.g. cargo build)
• generate a patch file via git diff
• in nixpkgs add the patch file to cargoPatches
• profit? (if the patch is not too large)

At least I think this could work.
You might be better off vendoring the lockfile.

>> The tarball with vendored dependencies contains a directory with the package’s name, which is normally composed of pname and version. This means that the vendored dependencies hash (cargoHash) is dependent on the package name and version. The cargoDepsName attribute can be used to use another name for the directory of vendored dependencies. For example, the hash can be made invariant to the version by setting cargoDepsName to pname: <...>

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
...
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}