Adds fypp linting support

[gnikit]

feat: add basic support for fypp

This is the start of incorporating fypp into VS Code

Hi @aradi I have gone ahead and added the simplest solution I could think off for fypp support to get the ball rolling and then,
I thought it would be a good idea to discuss some of the functionality we would want to include and problems I/we will have to address. I will start listing listing some of the things I have already thought off:

TODO

• Allow for arguments to be passed to fypp
• Incorporate the existing IncludeDirs passed to linters as --include=${} in fypp
• Implement an fypp interface to VS Code settings. For the preprocessor defines it makes sense we share them with fortls too. Have 2 settings and merge them in the backend for fortls or have a single option for both? I think the first one is better.
• Add fypp auto-download with pip
• Improve the compiler flags passed into the linter when fypp is enabled
• Add better safety checks for other compilers or add the appropriate compiler flags for fypp to work
• The linter serves diagnostics on the "expanded" source file we need to find a way to map back to the "compressed" file, i.e. pre-fypp to serve the diagnostics there. I don't know what resources does fypp provide to make that possible.

  I think the solution to this is use --line-numbering, at least for me that works.

• determine if Fixed or Free form
• Add unittests
• Add integration test for fypp
• Should the preprocessor definitions for fypp and fortls be merged? fortls understands normal Fortran preprocessor only. (I would like to discuss swapping to fypp if it can also handle normal preprocessor directives). deferred to a future conversation.
• Add support for ifort and nagfor if possible. To be implemented via feat: add fypp linting support for Intel and NAG #615

---

Fixes #215

[gnikit]

@aradi is fypp capable of handling normal Fortran preprocessor commands? I know that mixing normal preprocessor directive and fypp ones is not a good idea, so I am not talking about this case.

From my little local testing all should be good, but the normal preprocessor directives going into fortls and the fypp directives going into fypp should be kept separate.

Another topic that you might be interested in discussing is substituting or adding fypp support to fortls. Currently the normal preprocessor parser I have written is garbage and I am actively looking for better alternatives (in an attempt to avoid having to write my own). If fypp is able to somehow integrate with fortls providing both a normal and an fypp aware preprocessor that would be great.

[aradi]

No, fypp can't handle cpp-grammar. Actually, fypp does not have a proper lexer/tokenizer, it only looks for simple patterns via regular expressions. Most of the content is then passed to Python, which will parse then the expressions using its own parser. If you want to implement cpp-grammar, things get more complicated, as you would have to write a proper lexer and expression parser, so I think, it won't really profit from anything within fypp. I know that PreForM can deal with a bunch of the cpp-constructs, but not sure, whether that is of any help for you.

[awvwgk]

For a Python based cpp you can always use https://github.com/ned14/pcpp

[gnikit]

For a Python based cpp you can always use https://github.com/ned14/pcpp

Cheers @awvwgk pcpp has been on my radar for quite some time now, but I recall having some problems with it. Tbh, it might be worth just writing a C preproc from scratch.

[gnikit]

@aradi I think at this stage I will add fypp support only for GCC. My thought process behind this is that for ifort, nagfor (and any other compiler) we would have to create the actual fypp expanded files. I have found the correct way of doing that, see #614 but doing so in this PR would cause a lot of changes. More importantly, if we go down that path I am not sure having the on-the-fly (no temp files) fypp --> gfortran functionality would make a lot of sense.

[gnikit]

This is now done, any additional work will be implemented in a separate PR, @aradi @awvwgk have a look if you want. I will me merging this later today.