Intel Fortran debugger extension for vscode

[michaelkonecny]

This is a message explaining why I think debugging Fortran binaries in vscode on Windows is needed and what can be done to allow it.

The only way to debug Intel Fortran programs on Windows at the moment is using Visual Studio with the Intel Fortran bundle. While I understand that Visual Studio has been *the tool* for low-level programming on Windows for a very long time, the times, they inevitably are a-changing. Microsoft has invested a lot of effort into Visual Studio Code (vscode) which is by now a much better IDE for the majority of tasks for a number of reasons.
Aside from that, I have to admit I tend to dislike Visual Studio since the moment I had to start working with it 6 years ago, even before vscode was as good as it it now. I'll try to elaborate on the reasons below.

Reasons I dislike Visual Studio
Disclaimer: this is going to sound like a lot of complaining. I feel like all the arguments are valid, though. The problems I describe often appearing simultaneously, which poses real workflow issues both to me and everyone in a small Fortran team in the company I work for.

Clumsy build configuration
Example: A compiler has an option called /Qsave. Why do I have to remember it is also called Data->Local Variable Storage->ALL variables SAVE in Visual Studio?
This makes building projects for both Windows and Linux especially cumbersome.

The VS's build configuration GUI also makes it very hard to see which options have default values set and which have been changed.
It is also very hard to see whether the options are the same in different configurations/platforms.
(I realize I can choose All Configurations and then go through all the options to check. I still have to go through all the sections, though.)

I just want to be able to type all the compiler options I want in a single line in a makefile and be done.

Projects stop building for no good reason (the famous "The operation could not be completed" error)
This error randomly appears in the build output window. No further explanation, I have never found the cause. VS restart is needed each time. Sometimes, I have to restart VS dozens of times in a day because of this.

VS randomly freezes when editing fortran files
I'm suspecting this is an IntelliSense issue. This doesn't happen often, but is extra annoying when it does, as unsaved changes get lost.

Fortran editor slows down to an almost unusable speed after an hour of work, VS restart needed
Before becoming unusable, the editor gradually gets slower, which is annoying on its own. A person wants a responsive editor, not having to wait for a character they typed to appear in a second or more.

Supplied IntelliSense is very basic, doesn't offer much help
I realize this can be improved slightly by checking more options in Tools -> Options -> Text Editor -> Fortran -> Advanced. Even then, the advisor isn't very smart compared to others.
fortls, which can be added to vscode, provides a much better service, despite it being a one-man project and being buggy.
LFortran also has plans (https://gitlab.com/lfortran/lfortran/-/issues/12) on adding a language server interface running on top of their parser (which already works), which will probably soon become the best option.

There are three people in our dev team and all of us experience all of the above issues - this shows it's not just me or just my machine.

Some might say I could go and try to resolve/work around most of these issues. But apart from that taking forever, this isn't a systematic solution. Some of the issues above are inherent to Visual Studio and its poor architecture. vscode feels to be a much better design.

What is currently available in vscode:
- one can edit fortran files just fine with the help of fortls
I actually very much prefer this to writing code in Visual Studio. I only do debugging there.
- one can build projects, using Make or any similar tool
- one can partially debug fortran binaries as well using the cppvsdbg debug configuration type (see attached launch.json (just rename it to remove the .txt extension (a limitation of this forum)) for an example).
Breakpoints can be added after setting "debug.allowBreakpointsEverywhere": true, in settings.json and they do work.
Scalars, strings and user-defined types can be inspected in the debugger. Arrays (one of the most important features of Fortran), however, cannot be viewed.

What is missing:
The main thing that seems to be missing in vscode is the inspection of Fortran arrays in the debugger.
This would, IMO, make vscode a completely usable IDE for most of the tasks one needs.

What I'm trying to plea for here is that Intel supply a vscode debugger extension (https://code.visualstudio.com/api/extension-guides/debugger-extension) which would add fortran arrays debugging and allow breakpoints in .f90 files.

Something could perhaps be achieved by just using a .natvis file (https://docs.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022), which would a bit of a hack. A proper debugging extension would most certainly be a lot better, though.
If Intel doesn't have the resources available to do this, or it simply doesn't fit their strategy (which I think it should), maybe they can at least provide the information necessary for someone in the Fortran community to write the extensions on their own?
The main thing needed is the knowledge of how and where are arrays and their metadata stored in memory.

There seems to be a bit of a renaissance period going on around Fortran.
I'm a big fan of Ondrej Certik's https://fortran-lang.org/ project, for example.
This is to say Fortran is by no means a dead language.

We need to bring it to the 21st century, though, even for Windows users.

I'd like to hear reactions from other Windows users - would you also welcome this? Please give a thumbs up/leave a comment or a suggestion, so there's an idea of how many people want this - as well as a reaction from Intel - how can we make this a reality?

Thank you!
Michael Konecny

[JNichols]

When God needs a second opinion she asks Steve. 

[Steve_Lionel]

I don't disagree that VS Code support would be a benefit. All I am saying is that it is a major task, with Intel having to create or source significant components they now get from Microsoft. Development resources are finite. 

It may be that at some time in the future Microsoft decides to stop supporting third-party compilers in Visual Studio, at which point there would be some hard choices to make. I have no insight into Microsoft's thinking here, especially as they continue to develop Visual Studio. In the meantime, however, I could understand Intel management deciding that the benefit wasn't worth the cost.