Inserting period inside any token crashes zls

[Vexu]

To reproduce insert a period anywhere inside foo in

test {
    foo;
}

StackTrace

lib/zig/std/debug.zig:226:14: 0x25cbab in std.debug.assert (zls)
    if (!ok) unreachable; // assertion failure
             ^
/usr/lib/zig/std/zig/ast.zig:109:15: 0x30fc0d in std.zig.ast.Tree.tokenSlice (zls)
        assert(token.tag == token_tag);
              ^
/home/vexu/Documents/zig/zls/src/semantic_tokens.zig:898:44: 0x326888 in semantic_tokens.writeNodeTokens (zls)
            const rhs_str = tree.tokenSlice(data.rhs);
                                           ^
/home/vexu/Documents/zig/zls/src/semantic_tokens.zig:353:31: 0x31b689 in semantic_tokens.writeNodeTokens (zls)
                    try await @asyncCall(child_frame, {}, writeNodeTokens, .{ builder, arena, store, child });
                              ^
/home/vexu/Documents/zig/zls/src/semantic_tokens.zig:835:23: 0x32c222 in semantic_tokens.writeNodeTokens (zls)
            try await @asyncCall(child_frame, {}, writeNodeTokens, .{ builder, arena, store, node_data[node].rhs });
                      ^
/home/vexu/Documents/zig/zls/src/semantic_tokens.zig:1071:24: 0x2c4918 in semantic_tokens.writeAllSemanticTokens (zls)
        writeNodeTokens(&builder, arena, store, child) catch |err| switch (err) {
                       ^
/home/vexu/Documents/zig/zls/src/main.zig:1429:71: 0x2b2ba9 in semanticTokensFullHandler (zls)
        const token_array = try semantic_tokens.writeAllSemanticTokens(arena, &document_store, handle, offset_encoding);
                                                                      ^
/home/vexu/Documents/zig/zls/src/main.zig:1719:53: 0x2932b8 in processJsonRpc (zls)
                    done = extractErr(method_info[2](arena, id, request_obj, config));
                                                    ^
/home/vexu/Documents/zig/zls/src/main.zig:1962:27: 0x286404 in main (zls)
        try processJsonRpc(&arena, &json_parser, buf, config);
                          ^
/usr/lib/zig/std/start.zig:510:37: 0x27ceba in std.start.callMain (zls)
            const result = root.main() catch |err| {
                                    ^
/usr/lib/zig/std/start.zig:452:12: 0x260e8e in std.start.callMainWithArgs (zls)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/usr/lib/zig/std/start.zig:366:17: 0x25feb6 in std.start.posixCallMainAndExit (zls)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/usr/lib/zig/std/start.zig:279:5: 0x25fcc2 in std.start._start (zls)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^

Using latest Zls with latest Zig 0.9.0-dev.859+9c95f38a7.

[nektro]

Which editor/os/arch is this taking place?

[wtrmute]

This certainly happens absolutely all the time for me in Win10/VSCode/x86_64. Enough that VSCode will complain that ZLS has restarted five times in under three minutes and then refuse to restart it without closing and reopening the IDE itself.

For reference:

ZLS v0.9.0 (modified date of 2021-12-11 on the x86_64-windows tarball) ZLS for VSCode v1.0.4 VSCode v1.63.2 (commit 899d46d82c4c95423fb7e10e68eba52050e30ba3) Windows 10 Pro 64 bits version 21H1 (compiled on 2021-11-16)

[drew-gpf]

I can add that this has happened to me constantly on VSCode/Windows over the last many months. I did some debugging months ago but gave up after seeing that the version of the file known to zls included everything up to before the rhs(?) of the operation, which was strange because normally the entire file's contents are known. This is particularly annoying because it happens whenever the lhs isn't known, like with a cImport, but also only when there's already text to the right of the period.

[Techatrix]

Is this still an issue for some? #643 may have fixed this.

[Vexu]

Seems to work.