How a Zig IDE Could Work

https://matklad.github.io/2023/02/10/how-a-zig-ide-could-work.html

by todsacerdoti • 3 years ago

213 98 3 years ago

matklad.github.io

Reminds me of Eclipse days where they explained their Java compiler was more sophisticated than javac as they had to incrementally compile broken code as that is the main state of code during development.

Maybe we need to do the same here

systems• 3 years ago

What happened to Eclipse, is it still big for Java developers ??

DarkNova62• 3 years ago

For the most part, Eclipse has fallen into obscurity. But I doubt that it's competitors work any different in that regard.

IshKebab3• 3 years ago

I don't think so (IntelliJ is way more popular).

I think Eclipse is mostly popular these days as a platform for companies offering custom tools. For example Team Center (which is awful btw). Honestly Eclipse was always pretty awful and I have yet to use any Eclipse based software upon which that awfulness didn't at least leave a mild stench.

Check out this list: https://en.wikipedia.org/wiki/List_of_Eclipse-based_software

38362936482• 3 years ago

Eclipse the IDE is mostly dead, but its Java analysis was moved into a language server and is the goto option for people in vim, emacs and presumably VSC, though the last option isn't as open as the first two in what the extension actually uses under the hood.

pkphilip• 3 years ago

I still use it.

j16sdiz• 3 years ago

I love eclipse back in its day. It worked great for me until everybody started using Maven.

Eclipse tried to use the same approach for maven and wrote their own parser/processor to inject the Maven build file. This failed miserably.

nickcw2• 3 years ago

This is very different to most static languages.

From the article:

The whole process is lazy — only things transitively used from main are analyzed. Compiler won’t complain about something like

    fn unused() void {
        1 + "";
    }

This looks perfectly fine at the Zir level, and the compiler will not move beyond Zir unless the function is actually called somewhere.

planede2• 3 years ago

Yeah, it looks like Zig is a bit overly lazy.

As a comparison, what C++ does is that it differentiates between "dependent" and "non-dependent" expressions, where "dependent" means that it depends on some template parameter (analogous to comptime parameter here). "non-dependent" expressions are type-checked eagerly, while dependent expressions are only checked at instantiation time.

The design is certainly more complicated, even more so when you consider function overloading and name lookup, which can give different results if done late or early. But there are some upsides, and zig wouldn't need to deal with the additional complications of overloading.

edit: https://eel.is/c++draft/temp.dep

skywal_l• 3 years ago

Well it's basically like C macros. The C compiler won't see any code that's behind a deactivated macro. Same thing for zig here, except you don't have to deal with an unreadable macro language full of pitfalls. All is done in the language itself.

anonymoushn5• 3 years ago

I sort of like that Zig is lazy here, because in C++ a bunch of stuff that works in Zig just doesn't work.

In this line[0] a radix sort selects a function to read the next 8 or 16 bits of the input words. The C++ version of this code has to have readOneByte and readTwoBytes take an additional template parameter to control the return type:

  static constexpr auto readBucket = (BYTES_PER_LEVEL == 2) ? readTwoBytes<idx, udigit> : readOneByte<idx, udigit>;

because both parts of the expression are evaluated by the compiler and must be the same type, including the function's return type. This means we end up instantiating nonsense functions like readTwoBytes returning u8. Elsewhere in the same file, some should-be-impossible template instantiations have had to have their static_assert's removed, because C++ will instantiate them and then not insert any calls to them into the generated code. So one cannot use static_assert to say "If this is reachable, that's a bug, please fail compilation and return an error" because template instantiation and the execution of the static_assert does not imply that the function won't be immediately discarded as unreachable.

[0] https://github.com/alichraghi/zort/blob/main/src/radix.zig#L...

mdaniel2• 3 years ago

That is starkraving insanity, and now highlights why there is a whole submission about making a Zig IDE. So I guess if one wanted to do any refactoring, be sure to go through and uncomment every code flow in the app first

And look, I can appreciate lazy evaluation being awesome in some circumstance, but `fn wat() void { 1 + ""; }` just spits in the face of static typing

dilap2• 3 years ago

A nice thing you get in return tho is for separate platforms you can disable code just in the language itself; it doesn't need to be a preprocessor or or handled magically in the build system.

It's also not nearly as bad as a dynamically typed language: you might have broken code you won't realize until you try to use it, but you'll always realize at compile-time.

In dynamic languages you refactor and don't notice you broke stuff until runtime!

flohofwoe2• 3 years ago

It's pretty much a necessity for conditionally compiled platform-specific code if you don't have a text-based preprocessor with #ifdef/#endif.

All statically compiled languages need to skip compiling such code one way or another. Zig is just thinking this idea to the end and doesn't compile any dead code. I guess the recommended workflow is to have good test coverage. The test basically turns dead code back into live code.

throwawaymaths4• 3 years ago

It's kind of not. One way to think of it is roughly as follows: Zig is statically typed at runtime. It's dynamically typed at compile time.

Anyways it's not entirely crazy to think that maybe this sort of thing should be the province of static linters

nyberg2• 3 years ago

One would just run tests and rebuild for the supported targets? That will hit all comptime branches that you care about without needing to do anything else. I don't see how this is much worse? What you seem to be looking for is an "unused function" (https://github.com/ziglang/zig/issues/335) error instead as it catches that case unless you use the function in a branch that's not part of your target set (truly dead unused code).

There's support for invoking with qemu, wine, etc in the build system which allows you to run tests for other platforms.

A case where I've taken advantage if this is to have data structures and code adjust based on the expected page size and cache-line. There are also cases where things may be both comptime and runtime known depending on which platform that you target which is easy to handle by having the maybe comptime value be first in conditional branches.

Kukumber2• 3 years ago

Why should the compiler compile code that is not called/exported? that's a waste of processing power and therefore a waste of time

At best it should give you a warning that the function is not used, that's it

gavinhoward3• 3 years ago

Because the parser still has to skip it, especially if it's in a file with code that is used. The parser needs to know the beginning and the end to do so. This takes at least rudimentary parsing.

Oh, and the compiler may not know it's unused until it processes all files if it's a public function.

nickcw2• 3 years ago

I found it a surprise. However it is really useful when using comptime and doing those really awkward cross platform things (like delving into the innards of a stat_t) - your FreeBSD stuff with its different member names will be completely ignored on Linux.

titzer• 3 years ago

The Virgil compiler will typecheck all code given to it on the command-line and then only compile what is reachable from main() after running initialization in the internal interpreter, both code and data. Unused functions and fields and classes will simply never be visited for codegen.

gavinhoward3• 3 years ago

This is my biggest complaint against Zig's comptime.

I think it's possible to do comptime better, by putting comptime into separate files that can then "export" generated code.

junon2• 3 years ago

This is exactly how Rust's proc macros work.

nusaru• 3 years ago

Was hoping the author found a solution to (in my view) Zig's biggest shortcoming with generic types: a parameter that accepts all instances of a generic type must either (a) be declared as "anytype" or (b) also require a comptime parameter for the generic type argument. For example, the standard library passes around instances of std.io.Writer as anytype, so zls auto-completion doesn't work.

Also see: comptime interfaces proposal https://github.com/ziglang/zig/issues/1268

Kukumber2• 3 years ago

I agree with that, the language needs some love in that area

remorses2• 3 years ago

Interfaces are the most important thing Zig needs to implement ASAP

It would also help creating a uniform standard library, for example creating a Writer interface instead of having specific functions for files, sockets, buffers and all kind of types

jimbob45• 3 years ago

How are you going to implement interfaces if Zig is without classes in the first place?

fb03• 3 years ago

Context: Matklad is the main dev behind rust-analyzer

38362936482• 3 years ago

And a major dev behind intellij rust

molenzwiebel2• 3 years ago

He used to be. He recently left the rust-analyzer and rust compiler development teams to broaden his horizons, and is working full-time on a project that uses Zig now (which no doubt sparked this thought experiment).

faitswulff2• 3 years ago

Do you have a source for that? I'd be interested to read more about it

norir6• 3 years ago

works with incomplete and incorrect code

I know that this is a standard assumption, but I personally believe that it is a mistake to support this use case. It is a holdover from the batch processing days when getting feedback on your program could take minutes or hours. In those conditions, it was absolutely essential to try and proceed with a partial compilation even in the presence of errors or else iteration would have almost been impossible.

Now we live in an era of fast personal computers. With a language that is designed from the ground up with IDE support/rapid iteration in mind, you can get feedback with every keystroke. Everything is easier to design if you abort immediately on the first error, whether it is syntactic or semantic. Designing a parser with error recovery from syntax errors is a particularly dark art. On some level, you have to resort to guessing. It may work _most_ of the time, but to me there is nothing worse than a tool that is maybe correct.

When you advance past an error all of the code below the error is suspect. To give a trivial example, let's say you rename a function with 100 call sites without some kind of refactoring (automatic or manual). What benefit is there in showing the 100 new failures when the root cause is exactly where your cursor already is? There are cases like this that are even subtler where you are bombarded with downstream error messages that are confusing and taking you away from the actual root of the problem (c++ template errors come to mind). You may as well just gray out everything below the first error and reprocess it only when the error is fixed.

IshKebab3• 3 years ago

I think you have misunderstood. He's talking about IDE support. IDEs absolutely must be able to understand incomplete or incorrect code otherwise code completion will be completely useless. You literally only need code completion when your code is incomplete. The clue's in the name.

norir6• 3 years ago

I am focusing on the incorrect part. Let's say that you are adding some source code in the middle:

...

def add(x: Int, y: Int) = x + y

...

let x = ad|> I am using |> to denote the cursor location

...

I agree that where the |> is that the IDE should be able to autocomplete `add` for you. What I am saying is that it shouldn't process anything below the let statement because the code is broken there. Many IDEs and compilers will continue processing the file after the first error so that they can report all of the findings. That is what I am suggesting they not do.

hinkley• 3 years ago

I've had this conversation a few times over beers: I think we are collectively Doing It Wrong by not considering code edits as deltas and checkpoints.

Diffs often seem to fail to represent the actual change because they consider the delta from the last commit, which isn't the way we write code most of the time. If I go and insert a bunch of closing braces into the middle of a function, it's almost always because I'm dividing the function into two functions, or adding some missing error handling, or a corner case. So from the standpoint of a DAG representing the parse of the file, most of the time I expect the functions above and below to still be available in autocomplete even if I haven't balanced the tokens representing code blocks yet.

If you saw a bunch of functions and I break one, I expect the IDE to consider the function broken, not the file.

danybittel• 3 years ago

I recently watched an excellent Talk about IDE integration with Rust. Maybe worth checking out: https://youtu.be/N6b44kMS6OM

How a Zig IDE Could Work

Related Stories