Open Techatrix opened 3 months ago
Related is interfacing ZLS more directly with the compiler, for instance to provide accurate type information for variables even when complex comptime evaluation is involved. Upstream issue is ziglang/zig#615. I'm planning to begin work on this once incremental compilation is a little more mature -- @Techatrix, I'm hoping we'd be able to collaborate on integrating this with ZLS?
@Techatrix, I'm hoping we'd be able to collaborate on integrating this with ZLS?
Definitely. I'd be happy to help wherever I can to get the compiler protocol (or whatever it will be called) going.
I also see #2001 as a necessary precursor to get this feature integrated into ZLS. The first step is to get ZLS to keep the build runner in the background (and exchange error messages). This can then be expand to use the actual compiler protocol once it manifests.
Yep, agreed. I'd love to see #2001 get off the ground soon, since using incremental for a faster dev loop is somewhat viable now (there are definitely bugs, but I have used it while working on the compiler and it sorta-works!)
Instead of opening a separate issue, I'm guessing this problem will also be solved when this issue has been finished.
Running zig test
gives me error: expected error set type, found 'f32'
on the line where I define maybe_thing
. While ZLS doesn't show anything inside my editor.
test "own error" {
const maybe_thing: f32!u8 = 0;
const thing = maybe_thing catch 0.0;
try expect(@TypeOf(thing) == u8);
try expect(thing == 0);
}
I am new to the language and wanted to see if it had to be an error set or if it was more open, though my example with two kinds of numbers is a bit contrived.
In its current state, ZLS is only able to report syntax errors and errors that are provided by
zig ast-check
. Everything else (like semantic analysis) is not available. Here are some examples of errors that are not being reported:no field named 'foo' in 'bar'
function expected x argument(s), found y
expected type 'x', found 'y'
@compileError
(used bystd.debug.print
to report errors)There have been attempts in the past that tried to partially address this:
The most viable solution right now is the build-on-save feature. This issue will remain open until it is enabled by default. Probably once incremental compilation has matured enough.