Using the SourceMapper fails with Should be able to convert to usize: TryFromIntError(())

[stahlbauer]

I now have a SWC plugin ready for testing 🎉 and are facing some problems 💥.

Question(s) 1: What are general best practices for debugging SWC plugins? For example, how to get to meaningful stack traces? Which debugger to use? Is it possible to debug into the code from a NodeJS environment?

Question 2: I am facing a concrete failure in swc_plugin_runnter-0.77.4/src/memory_interop.rs:37.10 when running the plugin from a NodeJs environment. Any ideas?:

thread '<unnamed>' panicked at 'Should be able to convert to usize: TryFromIntError(())', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/swc_plugin_runner-0.77.4/src/memory_interop.rs:37:10
stack backtrace:
   0:     0x7f92af26a7a0 - <unknown>
   1:     0x7f92af292e9e - <unknown>
   2:     0x7f92af265de5 - <unknown>
...
  80:     0x7f91f3312827 - <unknown>
Error: failed to handle: Should be able to convert to usize: TryFromIntError(())

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: _ZN6v8impl12_GLOBAL__N_123FunctionCallbackWrapper6InvokeERKN2v820FunctionCallbackInfoINS2_5ValueEEE
   6: _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE
   7: _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE
   8: Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit

[kdy1]

Did you use

strip = "symbols"

?

This is very bad for debugging.

I prefer unit testing & debugging via test_fixture

[stahlbauer]

Would it make sense to run swc_plugin_runner with the plugin? (While cargo test in swc_plugin_runner currently does not execute any test.) Or is too much of the environment missing then? What is the role of #[cfg(feature = "__rkyv")]? Where will the feature be enabled?

[stahlbauer]

println! would also be fine. Then I have to figure out how to run a dev version of SWC with a plugin :-D

[kwonoj]

I'm not fully able to understand your question. If you are writing plugin you don't have direct way to deal with plugin runner from beginning as swc/core node.js binding should have it. If you are trying to run test inside of swc's repo itself for the plugin, that's not for the public usage.

[kwonoj]

And yes, if you want to print host side value you may need to build swc by yourself.

[kwonoj]

Overall, current debugging experience needs improvement regardless.

[stahlbauer]

In case you would have more pointers on fixing/debugging Should be able to convert to usize: TryFromIntError(()) I would be thankful.

I am also wondering how a minimal setup to reproduce the issue could look like. Maybe without the NodeJs part to reduce the complexity. Wouldn't the swc_plugin_runner be a good starting point?

[kdy1]

You can do the same thing we do for testing plugins.
Clone swc, and write a test in https://github.com/swc-project/swc/tree/caaf491da51b32424baf280513cf554c59aae72a/crates/swc_plugin_runner/tests and invoke it. It'll provide almost all information possible I guess

[stahlbauer]

For now, it is rather hard for me to set this up. Already running the test suite of SWC locally (as described in CONTRIBUTING.md) fails with test failures.

[stahlbauer]

By removing some of the transformation steps in my plugin I was able to get rid of the Error: failed to handle: Should be able to convert to usize: TryFromIntError(()). That is, the plugin seemed to have doing transformations that cause the trouble. Now, I will narrow down the manipulation a bit to identify the root cause.

[stahlbauer]

Some of the calls to span_to_snippet succeed, and eventually, a call fails.

[kdy1]

You can check for DUMMY_SP

[stahlbauer]

Checking this with span.is_dummy() does not prevent the failure.

[stahlbauer]

What is the relationship of plugin_source_map_proxy.rs and memory_interop.rs here? I can see many wasm32 annotations in the former. How can a particular call make the plugin fail?

[stahlbauer]

What about concurrency?

[stahlbauer]

The following seems to be sufficient to reproduce the problem:

#[plugin_transform]
pub fn process_transform(
    mut program: Program,
    metadata: TransformPluginProgramMetadata,
) -> Program {

    for i in 1..100000 {
        metadata.source_map.span_to_snippet(Span::new(BytePos(i), BytePos(i+10), SyntaxContext::empty()));
    }

[stahlbauer]

For now, I have created an issue: #6249