This pulls some of the complexity of calling the Silver compiler out of SilverLanguageService and into a seperate class, hopefully reducing the spagetti factor there.
Also, it turns out that there is a really easy solution to using an alternate Silver compiler jar over the specified one: just set the classpath when launching the language server, no classloader evilness needed. Not sure why I didn't think of that sooner... anyway, this should mostly avoid needing to re-install the VS code extension when making changes to the Silver compiler, aside from anything that changes the interface of the generated java functions that we hook into.
Documentation
There are some comments in the code.
Testing
Tried it out with various alternate jars specified in various ways.
Depends on #775
Changes
This pulls some of the complexity of calling the Silver compiler out of SilverLanguageService and into a seperate class, hopefully reducing the spagetti factor there.
Also, it turns out that there is a really easy solution to using an alternate Silver compiler jar over the specified one: just set the classpath when launching the language server, no classloader evilness needed. Not sure why I didn't think of that sooner... anyway, this should mostly avoid needing to re-install the VS code extension when making changes to the Silver compiler, aside from anything that changes the interface of the generated java functions that we hook into.
Documentation
There are some comments in the code.
Testing
Tried it out with various alternate jars specified in various ways.