For any editor plugins, it only needs watch such file and update its problems panels once any change detected, thoughts?
Note the downside is that if you have some unsaved files, that won’t be detected but we can still report syntax errors for those unsaved files. This is not the most fancy way of doing error diagnostics, but it’s probably the most reliable way of doing it ?
It’s an addition to the normal output ? we’ll still see errors and warnings on standard output ?
That could be easier to synchronise the external annotator in my case.
how errors would be serialised in the log ?
Why we plan to write a file is that the editor does not need run bsb, they just watch/read the build log
I think this is a great idea and should indeed make error diagnostics in the editor extremely solid.
It won’t help with Type Hints / Autocomplete though (which I hope will also be provided by the VS Code plugin at some point). Do you already have a plan how to implement those, too?
It’s a good idea but as @jfrolich mentioned with this approach diagnostics I think can’t be updated wihout saving the file.
It won’t help with Type Hints / Autocomplete though (which I hope will also be provided by the VS Code plugin at some point). Do you already have a plan how to implement those, too?
I’m also interested in this. is there any plan to achieve type information with a new approach or language server has to read from .cmt files or something like that.
Yeah. The difference being that what’s in the file is the latest run whereas in the terminal it’ll be streaming as usual.
The file will also persist after your build is done. Theoretically you can have other tools query it at a later time given that it’s not stale, but no promise for now.
Read-only diagnosis for editors is much more scalable. It means the editor itself (assuming you only have one open) doesn’t have to be the centralized point of building, aka you get to run your own bsb in the terminal, or have it as part of a larger build step without needing to negotiate with the editor to make sure you’re not stepping on each other’s toes, etc. It also means if you drag in a file from a different project, you don’t end up with some impedance mismatch of assuming that a single editor instance maps to a single project (e.g. you can show the errors from as many projects as you’d like in a single editor instance).
We do, but that part will be tackled differently. Unrelated to the feature above. Let’s focus on this issue first. Also, note that we’re not trying to reinvent the wheel; we’re only redoing the parts that should be solid. One big value proposition we have is a solid type system; for most users today, this isn’t even true if their primary interface to the type system is in-editor report, which is currently best-effort + mired by quite a few plugin-related problems. So that parts needs to be properly solved by ourselves. Type hints and autocomplete can defer to existing infra even.
That’s right. But it’s not like this particular feature would block what you’re asking for. We’re gonna postpone a real-time approach for now because we need a baseline of robustness. Also, it’s kinda hard to do real-time diagnosis while keeping soundness right now. Actually, to our knowledge, no language even offer the combination of soundness + real-time-ness in editor. At least we’re gonna check the first one now.
The type hints/autocomplete work will be rebased on reason-langauge-service plugging.
The thing we want to replace is the error diagnostics which is unreliable and misguided.
@Hongbo Does it mean that the error reporting is going to be responsibility of editor integration (client) rather than rescript language server? Or am I misunderstood the comment?
I think bob misunderstood your question @alex.fedoseev? It’s still the (language) server that reads that log file, if that’s what you’re asking. What did you mean by the client doing it?
Yes, it’s the server that reads it. I have to draft up the description for how this should be done to avoid stale diagnosis as much as possible. This’ll be useful for other editors with different logic like IntelliJ, Sublime Text, etc. Feel free to keep watching the rescript-vscode repo’s docs.
After working on this post about build system changes, I realized that we can capture the warnings output without making any disruptive changes to clients. That means you can still have -warn-error as a fine grained control. The build system will just capture the warnings magically.
It’s a bit more work to restore such behaviors, but I will revert such changes to make user experience better.
Also I would like to take this as an example: the rescript maintainers have to make trade off from time to time, it’s in our best interest to make user experience better regardless of how much extra work needs to be done. Sometimes users may not have as much context as maintainers on the design space.
