Sanity check - am I using this crate correctly? Doesn't seem to work for me for some reason when attempting to use with Vite

[sortofsleepy]

Summary

I have a workaround more or less; not for this issue exactly but it's just a way for me to keep working. Anyways I still wanted to ask out of curiosity.

I am trying to build a Vite plugin that loads a WASM module. I used the wasm-bindgen template as my starting point. In it, it provides a utils.rs file which declares

pub fn set_panic_hook() {
    // When the `console_error_panic_hook` feature is enabled, we can call the
    // `set_panic_hook` function at least once during initialization, and then
    // we will get better error messages if our code ever panics.
    //
    // For more details see
    // https://github.com/rustwasm/console_error_panic_hook#readme
    #[cfg(feature = "console_error_panic_hook")]
    console_error_panic_hook::set_once();
}

Currently when I attempt to use the function, I unfortunately am unable to get any specific error message/issue output from the console. I still see the general "unreachable" error and then a stack trace pointing to a memory location in the WASM module.

Even with a very simple test case like

pub fn process_file(){
    set_panic_hook();
    panic!("test");
}

I still get the general "unreachable" message.

Additional Details

Not sure if it might be the issue but maybe the issue lies somewhere in the interaction with Vite?

Thanks!

[ryanavella]

My problem may be unrelated as I'm not using Vite, but I'm seeing similar behavior.

I am currently relying on the unstable build-std feature, and I noticed that if I remove these options from my .cargo/config.toml it fixes the issue.

 [unstable]
-build-std = ["std", "panic_abort", "core", "alloc"]
-build-std-features = ["panic_immediate_abort"]

 [build]
 rustflags = [
     "-Clto",
-    "-Zvirtual-function-elimination",
 ]

 [profile.release]
 lto = true
 opt-level = 'z'
 debug = false
 codegen-units = 1
 panic = "abort"
 strip = true
 incremental = false

I can maybe understand why the virtual-function-elimination feature needs to be removed, as it is experimental and may be eagerly removing a vtable that console_error_panic_hook is relying on. But I don't see why build-std options should matter at all, I would expect the panic hook to run before aborting.

[ryanavella]

@sortofsleepy After browsing the issue tracker a bit more, I've come to the conclusion that console_error_panic_hook is no longer maintained, along with several other repositories under the rustwasm organization.

The merging of #21 is the last activity I see from @fitzgen in this repo, and their last 2-3 years of activity suggests they've been predominately tending to Bytecode Alliance crates. I don't see much (if any) activity in maintaining rustwasm organization crates. Note also that the WASM working group has no other active members.

As for alternatives, I don't see any good candidates among the current forks. The crate is quite small however (~150 LOC) and is dual MIT/Apache licensed, so I suspect we are just waiting on a dedicated volunteer to either fork it, or somehow get in contact with the dev and take over ownership.

[sortofsleepy]

After browsing the issue tracker a bit more, I've come to the conclusion that console_error_panic_hook is no longer maintained, along with several other repositories under the rustwasm organization.

Ah, oh well. Fortunately my use-case is non urgent but I would imagine yours and likely others aren't which is a little disappointing to hear.