fortran-lang / fortls

fortls - Fortran Language Server
https://fortls.fortran-lang.org/
MIT License
257 stars 41 forks source link

Fortls 3.0 crashes #398

Closed stefabat closed 6 months ago

stefabat commented 6 months ago

Describe the bug Fortls 3.0 crashes while parsing a file in vscode, using the modern fortran extension. In version 2.13 it was unable to parse that file, but it was not crashing, such that I could still use the LSP in VS code.

To Reproduce

  1. Get the file from https://github.com/cp2k/cp2k/blob/master/src/base/base_uses.f90
  2. Run fortls --debug_filepath base_uses.f90 --debug_parser
  3. Crashes because unable to parse line 42

The error is the following:

Traceback (most recent call last):
  File "/home/stefano/Miniconda/bin/fortls", line 8, in <module>
    sys.exit(main())
  File "/home/stefano/Miniconda/lib/python3.9/site-packages/fortls/__init__.py", line 21, in main
    debug_parser(args)
  File "/home/stefano/Miniconda/lib/python3.9/site-packages/fortls/debug.py", line 474, in debug_parser
    file_ast = file_obj.parse(debug=True, pp_defs=pp_defs, include_dirs=include_dirs)
  File "/home/stefano/Miniconda/lib/python3.9/site-packages/fortls/parsers/internal/parser.py", line 1331, in parse
    _, line, post_lines = self.get_code_line(
  File "/home/stefano/Miniconda/lib/python3.9/site-packages/fortls/parsers/internal/parser.py", line 1109, in get_code_line
    if FRegex.PP_ANY.match(next_line):
TypeError: expected string or bytes-like object

However, the error message i get from vscode is the following:

Error sending result: '<fortls.parsers.internal.parser.FortranFile object at 0x7a9448176d90>'. Reason: 'RecursionError('maximum recursion depth exceeded while pickling an object')'

Expected behavior Either to parse the file, or not crashing if unable to parse it.

Setup information (please complete the following information):

Configuration information (please complete the following information): I use all the defaults in VS code - Modern Fortran.

gnikit commented 6 months ago

I don't think this worked with v2.13.0 either. Locally I it fails the same way you described. Are you using any options for fortls?. The vscode error is about the recursion limit which you can increase by using --recursion_limit [VALUE]. To replicate the behaviour of vscode, you can do something like this.

fortls --debug_filepath src/base/base_uses.f90 --debug_rootpath . --debug_parser

Here I assume you open vscode on the root of the project, if not adjust the paths accordingly. You might also consider passing some additional options to fortls for the preprocessor since .f90 extensions are not parsed for preprocessor directives, have a look at the docs for a complete list of options

gnikit commented 6 months ago

This might be loosely related to this Issue https://github.com/fortran-lang/fortls/issues/236, where the preprocessor is supposed to #include Fortran AST nodes into a file, but it currently is unable to.

stefabat commented 6 months ago

Indeed the same problem occurs for v2.13.0, though, the vscode extension was able to connect to the language server and working properly despite the error (I just had a warning about the failed parsing of that particular file at every opening of the workspace).

I actually now reinstalled fortls v3.0.0 in a fresh conda environment and the behavior of the vscode extension (pointing to the freshly installed fortls) is the same as for v2.13.0, meaning that is again usable despite the failed parsing. Sorry for that, I don't know what went wrong with the update from v2.13.0 to v3.0.0 in the other conda environment.

In any case, continuing to debug this parsing issue: I don't use any special settings in the vscode extension, so I suppose that fortls is run without any additional option. I tried to add the --pp_suffixes .f90 option to get the file preprocessed, though, without luck. If I use

fortls --pp_suffixes .f90 --debug_filepath base_uses.f90 --debug_rootpath . --debug_parser

the file is not preprocessed. If I change the extension to .F90 it is preprocessed (without the --pp_suffixes option). So, I am not sure what is wrong there.

gnikit commented 6 months ago

I got to the bottom of this issue. I will issue a fix tomorrow and see if I can refactor the entire piece of code, since it is an absolute nightmare. The superficial reason is that the && of the preprocessor is confused with the line continuation marker &. The underlying reason is linked to the Issue I posted before, where the preprocessor info need to better/safer be included in the syntax to be parsed by the fortls parser.