-
-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no diagnostics for everything that depends on semantic analysis #2017
Comments
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? |
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 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.
The text was updated successfully, but these errors were encountered: