Visual Studio 2022 Language Server Protocol extension

Hi all,

I have recently started a job where I work with Fortran, and we use Visual Studio with Intel compiler integration for compiling/debugging our software. I saw that colleagues use VSCode with the Modern Fortran extension to work on the software, but then use VS to compile/debug. Since I saw that Modern Fortran uses the fortls language server protocol implementation by @gnikit, I thought I’d try to create an extension for VS2022 that uses fortls as well. My project can be found on github.

I saw that there already exists an extension for VS2017. I decided to create a new one, since I wanted to learn how to create an extension and to make it easier for me to solve problems when I encounter them.

I have not tested the extension much yet, but I have some questions about using fortls. Currently, the parsing of a larger codebase takes considerable time (minutes) on my machine. I have tried providing the --nthreads=22 option to fortls (default is 4, I have a machine with 24 virtual cores), but I saw no noticeable difference in the task manager (python always using ~8-12% of the CPU). Is it possible that Visual Studio’s implementation of the Language Server Protocol is the bottleneck here, feeding the files in a serial fashion to the language server?

My other question is about the --incremental_sync option: I saw that it is on by default in Modern Fortran, but so far I have not noticed an effect in Visual Studio when I add it to the command line arguments. What should I expect to see when I add this option?

Please let me know if you have any tips or suggestions!
Harmen

2 Likes

This is a pretty cool effort, nice work! The main reason why I didn’t bother authoring a VS extension was that maintaining it alongside the VSCode extension would be very difficult for one person, a lot of duplication and a lot of manhours, and since all of this would be unpaid work I chose not pursue it further. There is a comment of mine in a discussion somewhere in Fortran-lang Discourse (or maybe GitHub), where I provided a more detailed explanation of my reasons and I offered to build and maintain such an extension if there was funding, but unfortunately that never panned out.

I think one of the most important aspects of making such extensions, is maintenance and keeping them alive throughout the release cycles of Visual Studio. It is a non-trivial amount of work, but I wholeheartedly hope you keep up the schedule, I know many people will be happy with your extension.


fortls parallelises the parsing of source files with shared memory parallelism, so that functionality works well; a single large source file will be parsed by a single thread. Not sure what is happening in VS, or where the bottleneck is located, it could be any number of things, permissions, virtualisation costs, IO, etc. You will have to do some digging on your end to figure this one.

As a side note you should be using the number of physical cores, not the virtual.

On open documents are synced and then when altered on the changes of the document are processed by the server see.

Thank you for your reply, and for your fantastic work on fortls of course! So far, this was mostly an exploratory project to see if it would work, and so far it does. I think that it will be very useful for me personally, so I have the intention of keeping it up to date. One of the first things I can try is to make it work for VS2019 as well, since Intel Fortran does not appear to officially support the latest version of VS2022 unfortunately, so this may be useful.

I can try to dig deeper to figure out how files can be processed parallelly in Visual Studio. And thank you for the link to the LSP specification, I will set the default to incremental for now.