Vala-Linter has merged my contribution to convert it to a library, while it has been integrated into GVls, the GNOME Vala Language Server, to diagnose coding style “errors” based on elementary’s one.
Just now found GVls is crashing, that wasn’t the case for a while, and that is because the way #ValaLinter uses @vala_lang’s library, I think. While the recovery is fast enough, I don’t like that situation.
Vala-Linter can be executed as a command line, that may is harder to use, but if the crashing is too frequent that may needs to be used by GVls to reduce the effect of crashing or just because a software crash is not good.
Vala’s library is used in its internal Unit Test System, that catch any crash or undesirable behavior. The harder part on having a Unit Type system is to find a way to reproduce an issue and fix it; then write the test to make sure it has gone away, while in the future the test will be executed on any change you made in your code, ensuring the issue is not back.
GVls was used by Vala’s library to fix lot of warnings; the warnings don’t prevent Vala’s compiler to work, but make GVls to fail on its Unit Test system, so an external code test was created, to test your entire code in GVls and find an issue not present in the tests cases in GVls, currently more than 90.
Vala’s library has an internal Code Visitor, GVls learn to not use, because there is a lot of use cases, hard to find the exactly one, producing crashing because you assume the code path has been tested, but that is not the case when you talk about compiling code; you are traversing the parsed code in a ways Vala’s library hasn’t been tested for, and that makes your code path hard to debug. GVls opted to not use Vala’s library Code Visitor and use its own, providing more control on how the code is visited and used to find your code symbols.
Yes, filing an issue will help, the problem is to find the exactly code that produce the crash. If you know a way to debug a subprocess that may will help: GNOME Builder uses GVls by default for Vala code, so running it in a debug mode, that can produce a backtrace when GVls’s server crash will help to identify and study it in order to fix it.
Vala-Linter integration in GVls is good from the point of view of functionality: you get code style warnings on your favorite IDE. But its use of Code Visitor, may will produce recurrent crashing. If so, I’ll consider to switch to call Vala-Linter’s command line and parse its output, to isolate GVls server.
Coding in Vala will be improved soon, when uncrustify integration is in place and GVls project will explore the way we can use it to provide on-type-formatting, to avoid server crash, if present, when Code Visitor is in use.