dprint: Published npm package and vscode extension crash with "thread 'tokio-runtime-worker' panicked at 'assertion failed: !result.is_null()'"

Version: 0.36.0

In the published npm package and the vscode extension, dprint appears to crash with:

thread 'tokio-runtime-worker' panicked at 'assertion failed: !result.is_null()', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rkyv-0.7.39/src/impls/core/mod.rs:267:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Passing that environment variable to get more info:

thread 'tokio-runtime-worker' panicked at 'assertion failed: !result.is_null()', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rkyv-0.7.39/src/impls/core/mod.rs:267:17
stack backtrace:
thread 'tokio-runtime-worker' panicked at 'assertion failed: !result.is_null()', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rkyv-0.7.39/src/impls/core/mod.rs:267:17
thread 'tokio-runtime-worker' panicked at 'assertion failed: !result.is_null()', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rkyv-0.7.39/src/impls/core/mod.rs:267:17
   0: rust_begin_unwind
             at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/panicking.rs:64:14
   2: core::panicking::panic
             at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/panicking.rs:114:5
   3: rkyv::impls::core::<impl rkyv::DeserializeUnsized<[U],D> for [T]>::deserialize_unsized
   4: wasmer_engine_universal_artifact::serialize::SerializableModule::deserialize_from_archive
   5: wasmer_engine_universal_artifact::serialize::SerializableModule::deserialize
   6: wasmer_engine_universal::artifact::UniversalArtifact::deserialize
   7: <wasmer_engine_universal::engine::UniversalEngine as wasmer_engine::engine::Engine>::deserialize
   8: wasmer::sys::module::Module::deserialize
   9: dprint::plugins::implementations::wasm::load_instance::create_module
  10: dprint::plugins::implementations::wasm::plugin::WasmPlugin<TEnvironment>::new
  11: dprint::plugins::resolver::PluginResolver<TEnvironment>::resolve_plugin::{{closure}}
  12: dprint::plugins::resolver::PluginResolver<TEnvironment>::resolve_plugins::{{closure}}::{{closure}}::{{closure}}
  13: tokio::runtime::task::core::Core<T,S>::poll
  14: tokio::runtime::task::harness::Harness<T,S>::poll
  15: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  16: tokio::runtime::scheduler::multi_thread::worker::Context::run
  17: tokio::macros::scoped_tls::ScopedKey<T>::set
  18: tokio::runtime::scheduler::multi_thread::worker::run
  19: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  20: tokio::runtime::task::core::Core<T,S>::poll
  21: tokio::runtime::task::harness::Harness<T,S>::poll
  22: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:

I’m working around this at the moment by cargo install-ing dprint, but it’s a little annoying at the moment to not be able to format on save 😅

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (15 by maintainers)

Most upvoted comments

In fact, yeah, it’s totally reprodicible like that, now that I try. I’m running npx dprint and it will crash, but dprint succeeds (not even running fmt). Clear the cache, and then whichever one I run first works, the other crashing the next time I run it.