Completions broken due to missing semicolon (or any recoverable error)

[Jarred-Sumner]

Zig Version

0.11.0-dev.2317+46b2f1f70

Zig Language Server Version

HEAD

Steps to Reproduce

This started happening today? Not sure if code change causes it or if zls change

1. Put cursor on line 546: https://github.com/oven-sh/bun/blob/jarred/new-bundler/src/bundler/bundle_v2.zig#L532-L555
2. No completions for any non-top level scope types until the syntax is 100% valid.

Expected Behavior

Completions should appear

Actual Behavior

Completions do not appear

I suspect it's something to do with #1071

[Jarred-Sumner]

More minimal reproduction:

const std = @import("std");

fn HelloFn() type {
    return struct {};
}

pub const Hello = struct {
    pub fn hm(arg: *HelloFn(u64, void)) void {
        _ = arg;
        switch ((union {
            empty: u32,
            success: *anyopaque,
        }){ .success = undefined }) {
            .empty => |source_index| {
                _ = source_index;
            },
            .success => |*arg2| {
                // reference "arg" here
                {
                    arg2;
                }

            },
        }
    }
};

[Techatrix]

This is very similar to an Issue we had in ZLS Discord here.

This code snippet should also showcase the given problem:

pub var state: S = undefined;
pub const S = struct { foo: u32 };

pub fn main() void {
    state.
    {
        _ = state.foo;
    }
    state.foo;
}

I've initial concluded by stating that this Issue is hard to fix in ZLS because of how the zig parser got confused by the token sequence state.{. After giving this Issue another look, I think that fixing this by improving the error recovery of the Zig parser may also be a viable route.

Even if this can be fixed without modifying the parser, the error messages look really awful

[Jarred-Sumner]

Almost all the bugs I run into this have to do with the . character

What if when there's a syntax error and the last character typed was ., you retry parsing with a semicolon where the . character was placed? Doing that manually fixes the issue. Obviously that's a terrible hack, but it's an improvement over the current state.