#Linting panic handling in `no_std`

11 messages · Page 1 of 1 (latest)

last heron
#

I am trying to implement panic handling with no_std, targeting wasm. I have the following implementation:

#![no_std]

#[panic_handler]
fn handle_panic(_: &core::panic::PanicInfo) -> ! {
    loop {}
}

I see the following linting error in my IDE for the handle_panic function:

E0152
found duplicate lang item panic_impl
the lang item is first defined in crate std (which test depends on)...

I don't have any crate called test. My build .cargo/config.toml look like the following:

[build]
target = "wasm32-unknown-unknown"

I have tried setting rust-analyzer properties in my zed settings (cargo.target = "wasm32-unknwon-unknown, and checkOnSave.targets = false, to no avail.)

acoustic arrow
#

this sounds like you're trying to build in test mode, which won't work in this case

#

you can try setting harness = false on your target (bin or lib) in the Cargo.toml to prevent test from getting linked in

#

…or you could also #[cfg(not(test))] the custom panic handler so it does not conflict with the std one in that case

last heron
#

I see. Do I understand correctly that rustanalyzer is then making some assumptions about the environment (namely expecting std?) If so, I want to write tests, so it make sense to me that I would add something like #[cfg(not(test))], rather than change the assumptions made by the IDE. What exactly would be the difference between using not(test) and something like #[cfg(no_std)]?

#

with no(test), is it the case that handle_panic is not built when tests are, and no_std, when I am building with `no_std'? Do I need to have a separate target in my config to be able to test then?

acoustic arrow
#

rustanalyzer is then making some assumptions about the environment (namely expecting std?)
no, but it's asking Cargo to build tests (because otherwise it would not be able to offer assistance with your test code if you have any), which runs rustc --test, which links in test and thereby std.

#

with no(test), is it the case that handle_panic is not built when tests are
exactly

#

Do I need to have a separate target in my config to be able to test then?
No, the idea is that you would be successfully building in the usual fashion for tests, excluding your custom panic handler

#

that said, if you want to run tests on the wasm32-unknown-unknown target you have to use wasm-bindgen-test anyway which doesn't work like the usual test framework (I forget the details)