wasm rust start panic error

[tempcoderr]

Summary

The autocomplete is not working in my Java file, and when I check the Zed logs I am getting the following logs:

2025-06-18T16:33:47+05:30 INFO  [client] set status on client 245236: Connected { peer_id: PeerId { owner_id: 862, id: 1734764 }, connection_id: ConnectionId { owner_id: 0, id: 1 } }
2025-06-18T16:33:50+05:30 ERROR [project] error while executing at wasm backtrace:
    0: 0x2f1ec - java.wasm!__rustc[95feac21a9532783]::__rust_start_panic
    1: 0x2e386 - java.wasm!__rustc[95feac21a9532783]::rust_panic
    2: 0x2e359 - java.wasm!std::panicking::rust_panic_with_hook::hc20fbdbadfcc1625
    3: 0x2d1f7 - java.wasm!std::panicking::begin_panic_handler::{{closure}}::h1237330613601c3b
    4: 0x2d163 - java.wasm!std::sys::backtrace::__rust_end_short_backtrace::h207b568e8da931a1
    5: 0x2dcec - java.wasm!__rustc[95feac21a9532783]::rust_begin_unwind
    6: 0x395d1 - java.wasm!core::panicking::panic_fmt::he093f8ef6966d6c7
    7: 0x3eaf5 - java.wasm!core::str::slice_error_fail_rt::h3f929bc05cc00889
    8: 0x3d4ea - java.wasm!core::str::slice_error_fail::h491ea621a9efe9db
    9: 0x84fe - java.wasm!<java::Java as zed_extension_api::Extension>::label_for_completion::h699cabcf946214bb
   10: 0x20e4c - java.wasm!<zed_extension_api::Component as zed_extension_api::wit::Guest>::labels_for_completions::ha0eaaa6d4507185b
   11: 0x106fc - java.wasm!zed_extension_api::wit::_export_labels_for_completions_cabi::h3b0c04cc69aa162f
   12: 0x21437 - java.wasm!labels-for-completions
   13: 0x3f6c0 - java.wasm!labels-for-completions.command_export

Caused by:
    wasm trap: wasm `unreachable` instruction executed
2025-06-18T16:33:50+05:30 ERROR [project] wasm trap: cannot enter component instance

My Java file has the following code:

import java.util.*;

public class Solution {

    public static void main(String[] args) {
        Solution sol = new Solution();
        Input inp = new Input();

        Scanner scan = new Scanner(System.in);

        int[][] mat = inp.get2DIntArray(scan.nextLine());
        
        System.out.println(sol.solve(mat));

        scan.close();
    }

    public int solve(int[][] mat) {
        sout
        return 0;
    }
}

I have tried reinstalling Zed and the Java plugin.

Expected Behavior:
The autocomplete should have worked without giving any issues.

Zed.log file:
Zed.log

Zed Version and System Specs

Zed: v0.190.6 (Zed)
OS: macOS 15.5.0
Memory: 8 GiB
Architecture: aarch64

[SomeoneToIgnore]

Thank you for the nice bug report.

Unfortunately, we cannot help you in this repository, as it's a Zed Core repository, and the error happens in the Java plugin code (compiled into wasm).

Apparently whatever labels_for_completions implementation there is not working well with your editor state.

There seems to be 2 Java extensions in the corresponding Zed repo:

• https://github.com/zed-extensions/java/
• https://github.com/ABckh/zed-java-eclipse-jdtls

[tempcoderr]

@SomeoneToIgnore I had opened an issue on the Java extension GitHub repo as well, but it as also closed with the following comment:

This seems to me like this is some issue with how Zed runs extensions with WASM and maybe not an issue with this extension itself.

zed-extensions/java#62

[SomeoneToIgnore]

Thank you, let's leave it here until debugged better then.

[SomeoneToIgnore]

I've done brew install jdtls and installed only the Java extension (not the jdtls one).

Interestingly, the log is littered with various issues for me, but I cannot find the label_for_completion log anywhere in my output.
I see a lot of 2025-06-20T00:05:43+03:00 ERROR [project] Get code actions via jdtls failed: wasm trap: cannot enter component instance which look concerning but seems that it does not break the "regular" extension work?

The completions seem to work for me sometimes:

Screen.Recording.2025-06-20.at.00.05.38.mov

but most of the time the sout is pasted only.

If I do

to get the server logs, I seem to see the culprit:

and the server fails to send back more completion data (resolve) that should contain proper edits.
Why does it do so?

In the RPC messages tab (same place where the logs are), I see that the good case produces:

// Send:
{"jsonrpc":"2.0","id":119,"method":"completionItem/resolve","params":{"label":"sout","labelDetails":{"description":"print to standard out"},"kind":15,"detail":"print to standard out","sortText":"999999999","insertTextFormat":2,"textEdit":{"range":{"start":{"line":18,"character":8},"end":{"line":18,"character":12}},"newText":"System.out.println(${0});"},"command":{"title":"","command":"java.completion.onDidSelect","arguments":["7","1"]},"data":{"rid":"7","pid":"1"}}}

// Receive:
{"jsonrpc":"2.0","id":119,"result":{"label":"sout","labelDetails":{"description":"print to standard out"},"kind":15,"detail":"print to standard out","documentation":"System.out.println();","sortText":"999999999","insertTextFormat":2,"textEdit":{"range":{"start":{"line":18,"character":8},"end":{"line":18,"character":12}},"newText":"System.out.println(${0});"},"command":{"title":"","command":"java.completion.onDidSelect","arguments":["7","1"]}}}

and the bad case produces:

// Send:
{"jsonrpc":"2.0","id":49,"method":"completionItem/resolve","params":{"label":"sout","labelDetails":{"description":"print to standard out"},"kind":15,"detail":"print to standard out","sortText":"999999999","command":{"title":"","command":"java.completion.onDidSelect","arguments":["3","2"]},"data":{"rid":"3","pid":"2"}}}

// Receive:
{"jsonrpc":"2.0","id":49,"result":{"label":"sout","labelDetails":{"description":"print to standard out"},"kind":15,"detail":"print to standard out","documentation":"System.out.println();","sortText":"999999999","command":{"title":"","command":"java.completion.onDidSelect","arguments":["3","2"]}}}

Notice total absence of textEdit metadata in the 2nd example.

The backtrace points at

https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/1d5dafe28ffba1b037aca06c7362a7ad21ae4211/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CompletionResolveHandler.java#L102-L107

int proposalId = Integer.parseInt(data.get(DATA_FIELD_PROPOSAL_ID));
long requestId = Long.parseLong(data.get(DATA_FIELD_REQUEST_ID));
CompletionResponse completionResponse = CompletionResponses.get(requestId);
if (completionResponse == null || completionResponse.getProposals().size() <= proposalId) {
	throw new IllegalStateException("Invalid completion proposal");
}

but I am not sure what is wrong with that and what does it want.

We do seem to work with completions and their resolves ok for the other language servers I am aware of, so while it could be a bug on our side, I think we need to check what the language server actually wants.

As a theory, I suspect that Zed might resolve the completions too early by the language server's taste?
IIRC this is not a spec violation, as it's not specified when (and how many times) should the client resolve the completion item and Zed should do that for every visible item from the completion list.

Maybe @valentinegb knows anything?

[valentinegb]

Maybe @valentinegb knows anything?

Not much unfortunately ^^'

Initially I read wasm trap: wasm 'unreachable' instruction executed and thought unreachable!() had been hit somewhere in some Rust code. There aren't any calls to unreachable!() in the Java extension so I had assumed there must be one somewhere else in Zed. Maybe in one of the libraries Zed uses for running WASM?

I'm not totally sure if what you found @SomeoneToIgnore is actually related to this issue, but in any case, what I can say about that is, in my experience, JDTLS has shown some unexpected behavior in multiple instances. So I definitely wouldn't be surprised if this was some improper behavior on its side and not Zed's fault.

I'm sorry to say I don't have extensive knowledge of either JDTLS's inner workings or LSP, so I can't be of much help in this issue, but I wholly appreciate the efforts of anyone who gets involved and I'll pitch in when I can.