fortran-lang / fortls

fortls - Fortran Language Server

fortls - Fortran Language Server

fortls is an implementation of the Language Server Protocol (LSP) for Fortran using Python (3.7+).

All code editors that support LSP can integrate with fortls see the section Editor Integration in the documentation. Some supported code editors include: Visual Studio Code, Atom, Sublime Text, (Neo)Vim, and Emacs.

Features

• Project-wide and Document symbol detection and Renaming
• Hover support, Signature help and Auto-completion
• GoTo/Peek implementation and Find/Peek references
• Preprocessor support
• Documentation parsing (Doxygen and FORD styles)
• Access to multiple intrinsic modules and functions
  • ISO_FORTRAN_ENV GCC 11.2.0
  • ISO_C_BINDING GCC 11.2.0
  • IEEE_EXCEPTIONS, IEEE_ARITHMETIC, IEEE_FEATURES GCC 11.2.0
  • OpenMP OMP_LIB, OMP_LIB_KINDS v5.0
  • OpenACC OPENACC, OPENACC_KINDS v3.1
• Diagnostics
  • Multiple definitions with the same variable name
  • Variable definition masks definition from parent scope
  • Missing subroutine/function arguments
  • Unknown user-defined type used in TYPE/CLASS definition (only if visible in project)
  • Unclosed blocks/scopes
  • Invalid scope nesting
  • Unknown modules in USE statement
  • Unimplemented deferred type-bound procedures
  • Use of non-imported variables/objects in interface blocks
  • Statement placement errors (CONTAINS, IMPLICIT, IMPORT)
• Code actions
  • Generate type-bound procedures and implementation templates for deferred procedures

Notes/Limitations

• Signature help and hover does not handle elegantly overloaded functions i.e. interfaces

Documentation

The full documentation for fortls can be found at fortls.fortran-lang.org.

Installation

PyPi

pip install fortls

Anaconda

conda install -c conda-forge fortls

for more information about the Anaconda installation see

Common installation problems

It is NOT recommended having fortls and fortran-language-server simultaneously installed, since they use the same executable name. If you are having trouble getting fortls to work try uninstalling fortran-language-server and reinstalling fortls.

With pip

pip uninstall fortran-language-server
pip install fortls --upgrade

or with Anaconda

conda uninstall fortran-language-server
conda install -c conda-forge fortls

Settings

fortls can be configured through both the command line e.g. fortls --hover_signature or through a Configuration json file. The two interfaces are identical and a full list of the available options can be found in the Documentation or through fortls -h

An example for a Configuration file is given below

{
  "incremental_sync": true,
  "lowercase_intrinsics": true,
  "hover_signature": true,
  "use_signature_help": true,
  "excl_paths": ["tests/**", "tools/**"],
  "excl_suffixes": ["_skip.f90"],
  "include_dirs": ["include/**"],
  "pp_suffixes": [".F90", ".h"],
  "pp_defs": { "HAVE_HDF5": "", "MPI_Comm": "integer" }
}

Implemented server requests

Request	Description
workspace/symbol	Get workspace-wide symbols
textDocument/documentSymbol	Get document symbols e.g. functions, subroutines, etc.
textDocument/completion	Suggested tab-completion when typing
textDocument/signatureHelp	Get signature information at a given cursor position
textDocument/definition	GoTo definition/Peek definition
textDocument/references	Find all/Peek references
textDocument/documentHighlight	Same as textDocument/references
textDocument/hover	Show messages and signatures upon hover
textDocument/implementation	GoTo implementation/Peek implementation
textDocument/rename	Rename a symbol across the workspace
textDocument/didOpen	Document synchronisation upon opening
textDocument/didSave	Document synchronisation upon saving
textDocument/didClose	Document synchronisation upon closing
textDocument/didChange	Document synchronisation upon changes to the document
textDocument/codeAction	Experimental Generate code

Future plans

fortls has reached a point where it is feature complete and stable enough to be used in many modern Fortran projects without any issues. It does however still have fundamental limitations, namely its ability to understand all Fortran syntax and semantics that has been used throughout the 65+ years of the language. The good news is that we have a plan to address this issue!

We are excited to announce that we are working on creating a new Fortran Language Server based on the actively developed LFortran compiler 🎉. The new Language Server will be able to understand all Fortran syntax, be faster, and give more accurate autocompletion, hover and diagnostic information. That means we plan on investing any future funding on creating our new language server and ultimately creating a better user experience for everyone.

What about fortls?

Not to worry, fortls will continue to be here. We will keep fortls in active maintenance mode with bug fixes and new features from volunteer contributors, but otherwise we will be focusing our efforts into making the new language server using LFortran's parser a reality.

fortls vs fortran-language-server

This project was originally based on fortran-language-server LSP implementation, but the two projects have since diverged.

fortls (this project) is now developed independently of the upstream hansec/fortran-language-server project and contains numerous new features and bug fixes the original fortran-language-server does not.

For a complete and detailed list of the differences between the two Language Servers see the Documentation section: Unique fortls features (not in fortran-language-server)

The name of executable for this project has been chosen to remain fortls to allow for integration with pre-existing plugins and workflows, but it could change in the future.

Acknowledgements

This project would not have been possible without the original work of @hansec in fortran-language-server

Support

You can support Fortran-lang as a whole by donating at Fortran-lang - NumFOCUS.

Bug reports

When filing bugs please provide example code to reproduce the observed issue.

Security Policy

To report a security vulnerability please follow the instructions in our Security page.

License

This project is made available under the MIT License.

fortls's Issues

Investigate adding syntax highlighting

The language server can provide syntax highlighting. It would be interesting to explore potential improvements using this feature.

I would not consider adding full-blown support like in VSCode but if the server would serve additional scopes on an existing syntax that would be extremely beneficial since functions are not currently highlighted in any TextMate grammar file I have seen.

Type prefixed functions display wrong signature upon hover

This should display the function signature instead of a, what I can only assume without testing, is a var signature

integer function foo(x, y) result(z)      ! result does not need to be present for this to occur
  integer, intent(in) :: x, y
end function foo

Replace setup.py with pyproject.toml and setup.cfg

setup.py is slowly being phased out and replaced by pyproject.toml for configuration of the build system and setup.cfg for setuptools.

Use setuptools_scm for versioning

I notice here you've removed some code for auto-incrementing the version. I've recently been using setuptools_scm in all my python projects, which automatically sets the version from the latest git tag, and found it very useful.

Originally posted by @ZedThree in #31 (comment)

Change hover to use MarkupContent

The hover requests use the deprecated user interface MarkedString[]. We should change to MarkupContent which uses markdown to style the hover requests. we can then use our language ID to color our block see

Add support for LaTex in docstrings

I am in the process of rewritting the documentation parsing to be able to handle more formats. I think it would be possible to attempt to convert LaTex expressions found in the documentation to LaTex output. This can be combined with #45 since using Markdown to display LaTex seems like the easiest approach.

Always enable variable_hover

IMO variable_hover should always be enabled, and users should not be allowed to set that option.
This option will be deprecated in the next realse.

TODO:

• Add a deprecated group in the parser and ignore from passing it as an attribute

Visual Studio 2022 Support

Fortran language server currently does not have an extension for Visual Studio 2022.

Update Visual Studio extension to work on Visual Studio 2022 and publish it to VS marketplace.

Autoupdate language server version

Because fortls is used by multiple editors, it is the client's responsibility to have the latest version of fortls, however this creates a problem on our end. Users end up with outdated versions due to the client implementation not having a way to notify the user.

I think during initialisation we should check PyPi and if our version is older than that in the repo we should download the latest.

This should also minimise the maintenance of multiple versions since users will always be running the latest fortls version.

A flag should be added to disable this auto update in case new versions introduce breaking changes, but I would highly recommend against enabling that option.

Internal version in conda-forge distribution

I noticed that while the package version is correctly given by conda/mamba (fortls 2.2.5 py39h6e9494a_1 conda-forge), fortls --version yields the wrong version number (0.0.0) whereas the PyPi versions does not (2.5.5).

Toggle hover letter case

The letter case when hovering is fixed to uppercase. There sound be an option or more appropriately (imo) tied to the lowercase_intrinsics option for the hover to be lowercase too.

Migrated from hansec/fortran-language-server#216

Go to Definition does not work with EXTERNAL

Since I am dealing with an old-style Fortran project, functions and subroutines from other files are declared as EXTERNAL although most of them belong to the same project. ( Similar style could be found in LAPACK for example). If a subroutine is defined using EXTERNAL the "go-to-defintion" jumps to the external statement. Trying to jump to the implementation leads to en error "Implementation not found". If I comment out the EXTERNAL line and go to the defintion, it jumps to the file where the subroutine is defined.

Support for proper import host-association

See: hansec/fortran-language-server#187

Literal hover signature shows incorrect length of string

When hovering over a literal string the length of the string is overestimated because it also includes the quotes in the variable length

Preprocessor defines overrides fortran keyword resulting in scope errors

Hi,

First thank you for taking up this project and your numerous fixes!

I recently noticed a bug when a single TYPE IS is called in a SELECT TYPE block when an identifier is associated to the selector. The following error is raised in vscode: Invalid parent for "TYPE" declaration.

I am able to reproduce this behavior by removing lines 23 to 26 included in test/test_source/subdir/test_select.f90, yielding:

SUBROUTINE test_select_sub(self)
CLASS(parent), INTENT(inout) :: self
! Select statement with binding
SELECT TYPE(this=>self)
TYPE IS(child1)
  this%a
END SELECT
! Select statement without binding
SELECT TYPE(self)
TYPE IS(child1)
  self%a
END SELECT
END SUBROUTINE test_select_sub

This causes the test/test_server.py::test_comp to fail with TypeError: object of type 'NoneType' has no len().

To my knowledge, such a structure is valid (at least it compiles and works as expected on the Intel classic compiler).

Internal VS Code variable path resolution

Add variable resolution for internal VS Code variables like ${workspaceFolder}, ${workspaceFolderBaseName}, etc.

Add conda channel release

Alternatively to PyPi the server should be available for download through conda forge as well.
I have already done the setup, I only need to upload the tokens and setup the action.

END variable closes scope prematurely

Introduced via 477d095, when process_file end scope test was edited.
Now we using a variable with the name end will cause the scope to end.

MWE

program diag
    implicit none
    integer :: end
    if (.true.) then
        end = 10
    end if
end program diag

Use external parsers fparser / lfortran

The current parser for fortls is flimsy and commonly runs into problems when it comes to finding implementations of overloaded methods and preprocessor definitions. It would be interesting to see if fparser could be used to do the parsing of the source files instead.

Potential problems:

1. Does not support f2018 and newer standards
2. Parsing might not work in parallel

Show constant parameter value in hover

See: hansec/fortran-language-server#116

Multiline function and subroutine hover displays duplicates

If the argument list in a function or a subroutine spans multiple lines, hovering on an argument that is not on the scope start will show two signatures

MWE

   real function foo(val1, &
                     val2) &
                     result(val4)

      integer :: val1, val2
   end function foo

I think we should keep only the latter definition, which includes the variable name. Currently the default behaviour is to just show the type

Use-directive ordering issue

See: hansec/fortran-language-server#184

Fortls not working with Python 3.6

Hello,

Ok I think I need to update to python >3.7 sorry for the inconvenience

######################
I installed fortls on RockyLinux using pip3 install fortls --user
That worked

I need fortls for VsCode but I get an error
'''Error starting fortls: Check that fortls is in your PATH or that "fortran.fortls.path" is pointing to a fortls binary.'''

I changed it from standard setting, to "fortls" to my actual binary in "/home/mdeberts/.local/bin/fortls" but the error remains, in UI and in settings.json - nothing worked.

Also if I type in terminal "fortls" I get the following error:

[mdeberts@oflks103 ~]$ fortls
Traceback (most recent call last):
File "/home/mdeberts/.local/bin/fortls", line 7, in
from fortls.init import main
File "/home/mdeberts/.local/lib/python3.6/site-packages/fortls/init.py", line 10, in
from .helper_functions import resolve_globs, only_dirs
File "/home/mdeberts/.local/lib/python3.6/site-packages/fortls/helper_functions.py", line 1
from future import annotations
^
SyntaxError: future feature annotations is not defined

Request textDocument/implementation failed.

If I simple do right click + "go to Implementations" within VsCode on mod(5,2) I get the following error
No .fortls file or changed settings (maybe I did something wrong without noticing but as far as I know I did not change anything)

program myprogram
   implicit none
   integer :: i
   i = mod(5,2)
end program myprogram

[INFO - 16:02:21] fortls - Fortran Language Server 2.2.5 Initialized
[Error - 4:03:37 PM] Request textDocument/implementation failed.
  Message: 'NoneType' object has no attribute 'get_type'
  Code: -32603 
[object Object]

Hover on associated blocks does not display types

Hovering over variables that have been associated in an ASSOCIATE block yield no signature.

program test
    implicit none
    integer :: a
    testing: associate(c => 1)
        print*, c
    end associate testing
    associate(c => a)
        print*, c
    end associate
end program test

Case select with forall causes unexpected end of scope

The following code will result into an unexpected end of scope

program test_case_select_forall
   implicit none
   integer :: i, dim=3, a(10) = 2

   select case (dim)
    case(3)
      forall(i=1:10)
         a(i) = a(i) **2
      end forall
    case default
      call abort()
   end select
end program test_case_select_forall

Feature request: documentHighlightProvider support

Currently fortls does not implement the documentHighlightProvider language server feature, which makes emacs lsp-mode do not have symbol highlighting feature. Can you implement this feature ?

Unify command line and config file interfaces

Currently the language server has effectivelly 2 disntinct interfaces that need to constantly be updated when a change in just one of the two is made.
The solution to this would be to unify the interfaces into a single one.
We can pass the command line arguments into the LangServer class and set them as class attributes

Renaming only imported statements yields incorrect results

Trying to rename localname in use rename_mod2, only : localname => originalname
will rename localname in the use statement but not in the subsequent scopes and will erroneously rename originalname

module rename_mod1
real(8) :: var1
end module rename_mod1
!
module rename_mod2
use rename_mod1, only: renamed_var1 => var1
integer :: originalname
end module rename_mod2
!
subroutine test_rename_sub()
use rename_mod2, only : localname => originalname, renamed_var2 => renamed_var1
implicit none
!
localname = 4
renamed_var2 = 4    
end subroutine test_rename_sub

Additional MWE to consider; renaming tr does not propagate

module rename
contains
    subroutine test(a)
        print*,a
    end subroutine test
end module rename

program main
    use mod, tr => test
    call tr(2.0)
end program main

Space separated keywords not being parsed

There has been a bug in the server where keywords like intent or pass will not be parsed if there are spaces between their arguments

    subroutine test_sub(list)
        integer, intent ( in ) :: list
    end subroutine test_sub

Rewrite unittests so debuggers can step into Popen call

The way that we have setup our unittests we cannot actively debug calls to the server.
More specifically, we need to use subprocess.Popen to input the binary buffer to the server, however we also pass the shell=True variable which causes the process to become inaccessible to (any) Python debugger.

rewrite the tests without the use of shell

Preprocessor statements in declarations break parsing

See: hansec/fortran-language-server#203

Sublime editor support

Hey @gnikit, just read your two cents at fortran-lang/fpm#596 (comment), and thought I might try and get involved.

Personally, my favorite editor is Sublime. So far I've been using the SublimeFortran package, however it isn't actively supported. If I'm not mistaken this package only provides syntax highlighting.

I've found out there is an LSP Sublime package which currently uses the original hansec branch.

I'll use this issue to document my progress setting up your fork, and if successful we could add Sublime to the list of editors?

Overloaded functions

From the original repo See: hansec/fortran-language-server#135

The solution that I have in mind is to use the function's/subroutine's signature help (--use_signature_help) to distinguish between different instances of an interface.

• When typing the function/subroutine name it should show the number of "overloads"
• When typing the argument list it should be able to filter through the overloads available throughout the project
• When hovering over the fully typed expression it should show only a single definition, matching to the function/subroutine
• Ideally we should be able to show the hover message with those little arrows that allow you to navigate between different defs
• TODO: make sure that the autocomplete of an overloaded interface will autocomplete to the interfaces name and not the name of the function/subroutine chosen from within the interface

Hover over literal and parameter strings does not show value

The hover over a constant or a literal strings will not show the hover parameter

Unify Fortran sources and preprocessor include directories

I think that using a separate directory for the preprocessor includes, which by design, does not include any of the source directories other than CWD is counterintuitive and should not be the norm.

I think that passing source files (including preprocessor files) should be a single option. More extensions for source files can be specified with the option incl_suffixes. For the cases were files that contain preprocessor commands, that we don't want to parse, with extensions matching those of incl_suffixes and are randomly scattered in the source tree i.e. we cannot exclude them with any of the exclude patterns should not be supported.

fortls, like almost all Language Servers, assumes some logical ordering of one's project, where files that are not needed have been somehow sanitised. The main comparison that I am drawing is the LS of C/C++.

Show POINTER attribute when hovering

A variable that is defined as a pointer will not display the pointer attribute whilst hovering.
One would expect the opposite.

Functions returning arrays hover handling

Currently hovering on a function that returns an array will either produce the variable signature (which is incorrect and has now been fixed in PR #49 ) or it will display the function signature with the array dimensions in the function definition.

Although that is convenient, the hover request displays invalid FORTRAN syntax which in turn causes syntax highlighting in VSCode to break. IMO all parts of the server, except snippets which contain placeholders, should be producing valid FORTRAN syntax.

I propose the following hover message

real function foo(arg) result(val)
  real, intent(in) :: arg
  real, dimension(10,10) :: val

instead of

real dimension(10,10) function foo(arg) result(val)
  real, intent(in) :: arg

This would also mean that #47 would now have to include an additional line with the result variable at all times

Improve code coverage

There are some aspects of the server that we do not actively test. Submit some fortran source code with examples.
See this for places in the code-base that require more coverage.

Keywords always sorted on Windows

For some reason the global keyword seems to be ignored and not setting the global variable sort_keywords on Windows machines.

Add support for GoTo Implementation in submodules

fortls can detect the interface in a module, but not its implementation in a submodule, see this example.

MODULE MOD

IMPLICIT NONE

!==============================================================================
TYPE :: TYP
    REAL(KIND=8) :: value
CONTAINS
    PROCEDURE :: PRC1 => PRC_PRC1
END TYPE TYP
!==============================================================================


!==============================================================================
INTERFACE
    MODULE  SUBROUTINE PRC_PRC1(this)

        IMPLICIT NONE

        CLASS(TYP), INTENT(INOUT) :: this

    END SUBROUTINE PRC_PRC1
END INTERFACE
!==============================================================================

END MODULE MOD

SUBMODULE(MOD) SMOD

IMPLICIT NONE

CONTAINS

!==============================================================================
MODULE SUBROUTINE PRC_PRC1(this)

    IMPLICIT NONE

    CLASS(TYP), INTENT(INOUT) :: this

    this%value = 0

END SUBROUTINE PRC_PRC1
!==============================================================================

END SUBMODULE SMOD

INCLUDE files not in scope

if we include a file that is not in the AST file and attempt to go to its definition, then an exception is thrown

program test
include 'mpi.f'
implicit none
end program test

`fortls` 2.2.6 upgrade difficulties

Hi
Updating from 2.2.5 to the newest Version is causing some troubles:

Win 11
VS Code 1.65.1
Python 310

Honour import statement in abstract interface blocks for completions

See: hansec/fortran-language-server#90

module mod
  implicit none
  type :: type1
    real(kind=8) :: value
  contains
    procedure :: abs_int => abs_int1
  end type type1
  type :: type2
    type(type1) :: t
  end type type2
  interface
    subroutine abs_int1(this)
      import type1
      class(type1), intent(inout) :: this ! only type1
    end subroutine abs_int1
    subroutine abs_int2(this)
      import, only: type2
      class(type2), intent(inout) :: this ! only type2
    end subroutine abs_int2
    subroutine abs_int3(this)
      import, none
      class(type1), intent(inout) :: this ! no comp results
    end subroutine abs_int3
    subroutine abs_int4(this)
      import, all
      class(type1), intent(inout) :: this ! type1 and type2
    end subroutine abs_int4
    subroutine abs_int5(this)
      import
      class(type1), intent(inout) :: this ! type1 and type2
    end subroutine abs_int5
    subroutine abs_int6(this)
      import type1
      import type2
      class(type1), intent(inout) :: this ! type1 and type2
    end subroutine abs_int6
  end interface
end module mod

program main
  use mod
  type(type1) :: obj
  call obj%abs_int()
end program main

Code completion broken in v2.1.0

With v2.1.0, code completion doesn't correctly expand argument names. For example, call bar completes to call bar(1:{int}) instead of call bar(int) in the MVCE below.

I've used git bisect and the steps below to track it back to a82f4e2

Steps to reproduce

Save the following as mvce.f90:

program foo
  implicit none

  call bar

contains
  subroutine bar(int)
    integer, intent(in) :: int
    print*, int
  end subroutine bar
end program foo

and run: fortls --debug_completion --debug_filepath mvce.f90 --debug_line 4 --debug_char 10 --debug_full_result

Expected output

Testing "textDocument/completion" request:
  File = "mvce.f90"
  Line = 4
  Char = 10

  Results:
[
  {
    "label": "bar",
    "insertText": "bar(${1:int})",
    "insertTextFormat": 2,
    "kind": 3,
    "detail": "SUBROUTINE bar(int)",
    "documentation": "SUBROUTINE bar(int)"
  },
  {
    "label": "BACKTRACE",
    "kind": 3,
    "detail": "SUBROUTINE BACKTRACE()",
    "documentation": "BACKTRACE shows a backtrace at an arbitrary place in user code. Program execution continues normally afterwards. The backtrace information is printed to the unit corresponding to ERROR_UNIT in ISO_FORTRAN_ENV."
  }
]

Actual output

produces:

Testing "textDocument/completion" request:
  File = "mvce.f90"
  Line = 4
  Char = 10

  Results:
[
  {
    "label": "bar",
    "insertText": "bar(${1}:{int})",
    "insertTextFormat": 2,
    "kind": 3,
    "detail": "SUBROUTINE bar(int)",
    "documentation": "SUBROUTINE bar(int)"
  },
  {
    "label": "BACKTRACE",
    "kind": 3,
    "detail": "SUBROUTINE BACKTRACE()",
    "documentation": "BACKTRACE shows a backtrace at an arbitrary place in user code. Program execution continues normally afterwards. The backtrace information is printed to the unit corresponding to ERROR_UNIT in ISO_FORTRAN_ENV."
  }
]

Functions with multiple keywords display incorrect hover

If a function is defined with keyword1 type keyword2 function name() keyword1 will not be shown upon hover.

! function with type on definition, return and keywords
pure integer elemental function fun5(arg) result(retval)
    integer, intent(in) :: arg
end function fun5

Standardise function hover

Hover over functions can produce vastly different results depending on how the function is written.
Hover results will be different depending on whether the function type and the function result are present.
The output should be standardised regardless of how the function is written.

! simple function
function fun1(arg)
    integer, intent(in) :: arg
    integer :: fun1
end function fun1

! function with type on definition, implied result
integer function fun2(arg)
    integer, intent(in) :: arg
end function fun2

! function with return
function fun3(arg) result(retval)
    integer, intent(in) :: arg
    integer :: retval
end function fun3

! function with type on definition and return
integer function fun4(arg) result(retval)
    integer, intent(in) :: arg
end function fun4

Increase build-in keywords offer for autocomplete

Currently the Fortran keywords offered for autocompletion is a relatively small set of what is available in Fortran.
I would like to substantially increase that to make typing definitions less cumbersome.

Private variable declaration in module seen in other scopes

See: hansec/fortran-language-server#191

Show constant parameter value in hover

See: hansec/fortran-language-server#116