Giter Club home page Giter Club logo

mesonlsp's Introduction

MesonLSP

Copr build status CodeFactor codecov

Packaging status OpenSSF Best Practices

A reimplementation of my Meson language server in C++ (Formerly Swift). It's there for providing code intelligence in editors using the language server protocol.

Current feature set

  • Hovering
  • Symbol resolving
  • Jump-To-Definition
  • Jump-To-Subdir
  • A basic set of diagnostics
  • Formatting
  • Document symbols
  • Autocompletion (Somewhat working)
  • Inlay hints
  • Highlighting
  • Automatic subproject/wrap downloads
  • Code actions
  • Renaming
  • Semantic Highlighting
  • Folding

Auto Completion Diagnostics Hover Hover Inlay Hints Special integration for pkg-config

Limitations

  • set_variable/get_variable with non-constant variable name will fail in more complex cases.
  • subdir with non-constant subdir name will fail in more complex cases.
  • Type deduction is not 100% correct yet
  • Type definitions may have minor errors regarding:
    • Is this argument optional?
    • What is the type of the argument?

Why a reimplementation?

The first version, written in Vala, had some code maintenance problems because basically everything was done in one file. I had the choice between untangling that mess or rewriting it as cleanly as possible. I have chosen the latter because I wanted to learn Swift.

And now rewrote it in C++ for more performance, a better buildsystem and to address technical debt.

Installation

Install the language server

Easy way

Compile from source

# Install the dependencies...
git clone https://github.com/JCWasmx86/MesonLSP
cd MesonLSP
meson setup _build --buildtype release -Db_lto=true
ninja -C _build
sudo ninja -C _build install

Connect with your editor

VSCode (Official support)

Install the official meson extension. If you don't have MesonLSP in the PATH, it will ask you whether it should download the language server.

GNOME Builder 45 and GNOME Builder Nightly (Official support)

You have to do nothing. The editor already has the support code for MesonLSP. All you have to do is install the language server.

Kate (No official support)

Add this JSON to ~/.config/kate/lspclient/settings.json:

{
  "servers": {
    "meson": {
      "command": [
        "mesonlsp",
        "--lsp"
      ],
      "rootIndicationFileNames": [
        "meson.build",
        "meson_options.txt"
      ],
      "url": "https://github.com/JCWasmx86/MesonLSP",
      "highlightingModeRegex": "^Meson$"
    }
  }
}

After that, a dialog should be shown asking you to confirm that the language server may be started.

Neovim

nvim-lspconfig has the mesonlsp server configuration you can use.

For coc.nvim, add this JSON to :CocConfig:

{
    "languageserver": {
        "meson": {
            "command": "MesonLSP",
            "args": ["--lsp"],
            "rootPatterns": ["meson.build"],
            "filetypes": ["meson"]
        }
    }
}

Want to contribute?

Take an item from the TODO list in PROGRESS.md and work on it. Feel free to join the matrix channel #mesonlsp:matrix.org

Projects I tested the language server with

mesonlsp's People

Contributors

dependabot[bot] avatar ferdnyc avatar fwcd avatar imgbotapp avatar jcwasmx86 avatar polyzen avatar ptomato avatar qulogic avatar step-security-bot avatar sweep-ai[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

mesonlsp's Issues

Crashing when viewing a diff in VSCode

Describe the bug
Server crashes when viewing a diff in VSCode.

To Reproduce
Steps to reproduce the behavior:
Open a diff in VSCode like what I did.

Expected behavior
Don't crash

Screenshots/Screencasts
image

System info

  • OS: Fedora 39 (COPR)
  • Editor: VSCode
  • Version: 3.1.2

Rename does not work in VSCode

Describe the bug
If using GTK, renaming e.g. graphene_req to graphene_req2 renames the identifier at the beginning of the file to graphene_req22. Renaming it back to graphene_req yields Rename failed to apply edits

To Reproduce
Steps to reproduce the behavior:

  1. Clone https://github.com/GNOME/gtk
  2. Open the project in VSCode
  3. Rename the identifier at line 22 (At time of writing)
  4. Renaming breaks

Expected behavior
Renaming works

Screenshots/Screencasts
If applicable, add screenshots/screencasts to help explain your problem.

System info

  • OS: Fedora 38, from git
  • Editor: VSCode
  • Version: git

Additional context
Add any other context about the problem here.

`default_options` accepts a dictionary since meson 1.2.0

Describe the bug
default_options accepts a dictionary since meson 1.2.0. Swift-MesonLSP only changed the AST on project function, while dependency and subproject also have default_options.

To Reproduce
Steps to reproduce the behavior:

  1. Make a demo meson.build file like:
project('demo', 'c', default_options: {'c_std': 'c11'})
subproject('subdemo', default_options: {'c_std': 'c17'})
dependency('libdep', default_options: {'some_feature': 'enabled'})
  1. Swift-MesonLSP will return error on the last two lines:
Expected list(str), got dict(str)

Expected behavior
Not reporting the errors.

Screenshots/Screencasts
N/A

System info

  • OS: Debian 12, Swift-MesonLSP installed from swift-mesonlsp-apt-repo
  • Editor: VSCode
  • Version: 3.1.3

Additional context

[Post-RIIC++] Port to macOS

  • From a code POV it's finished
  • Distribution: Is signing needed?
  • Figure out how to bundle x86/ARM in one file

[Maybe Post-RIIC++] Add custom parser

tree-sitter only gives use "ERROR" nodes if there is a syntax error. To make mesonlsp more user-friendly, another parser should be added.

Notes:

  • tree-sitter-meson and handwritten parser should co-exist => Switching possible
  • C++-Implementation
  • No reuse of muon AST (As I want to write the parser myself => Control over everything)
  • Better performance would be nice, but isn't that important. (But equal performance is required!)

pre-commit-hooks support

Describe the solution you'd like
Provide a .pre-commit-hooks.yaml to allow user use it to format and lint meson code.
That is, mesonlsp must have a CLI port to format and lint meson files.

TIA!

Emit diagnostics for meson_options.txt/meson.options

  • Implement a new visitor for the options file
  • Emit diagnostics/update diagnostics

Diagnostics:

  • Reserved option name
  • Invalid option name
  • Duplicate options
  • Duplicate ComboOpt/ArrayOpt options

Other stuff:

  • Make semantic tokens work in these files

[Post-RIIC++] Implement linter

mesonlsp will stay the same. A tool called mesonlint will be introduced that can be used as a full-blown linter. Features

  • Formatting with (statically linked) muon.
  • Use of a config file (.meson_lint?, maybe avoid using the meson prefix too much) for passing analysis/formatting options (E.g. to disable/enable checks or to set the severity)
  • CI Integration (See #40)

Build Swift-MesonLSP using meson

This is a meson language server. That's why it would be nice, if it could be built using meson itself.

It requires porting all dependencies to meson and patching a bit of meson.

Patches needed:

  • Automatically generate module.modulemap for libraries and append it to the swiftc command using -Xcc
  • Use -parse-as-library for executables with just one file
  • Use -parse-as-library for libraries with just one file
  • Add swift_args

Dependencies to port:

  • bitbytedata
  • console-kit
  • indexstore-db
  • perfect-iniparser
  • sourcekit-lsp
  • swcompression
  • swift-argument-parser
  • swift-asn1
  • swift-backtrace
  • swift-certificates
  • swift-collections
  • swift-crypto
  • swift-driver
  • swifter
  • swift-llbuild
  • swift-log
  • swift-package-manager
  • swift-syntax
  • swift-system
  • swift-tools-support-core
  • swifttreesitter
  • tree-sitter-meson
  • yams

Generated using swift package show-dependencies --format flatlist|sed 's/^/- [ ] /g'|sort|uniq

Support run muon with existing muon_fmt.ini

Is your feature request related to a problem? Please describe.
I have muon_fmt.ini defined in my working directory, and I would like Swift-MesonLSP run just muon fmt instead of passing generated configure file into.

Describe the solution you'd like

  1. Just call muon fmt <meson.build> when formatting.
  2. Provide an option to specify an ini file.
  3. Fallback to the generated configuration.

Describe alternatives you've considered
As described above

Will you write a patch?
No in recent days.

Will you maintain it, if you submit a patch?
If I really have patched it, I may.

Additional context
N/A

Rename does not work in Kate

Describe the bug
If using GTK, renaming e.g. graphene_req to graphene_req2 renames the identifier at the beginning of the file to graphene_req2graphene_req2. Renaming it back to graphene_req gives graphene_reqgraphene_req

To Reproduce
Steps to reproduce the behavior:

  1. Clone https://github.com/GNOME/gtk
  2. Open the project in VSCode
  3. Rename the identifier at line 22 (At time of writing)
  4. Renaming breaks

Expected behavior
Renaming works

Screenshots/Screencasts
If applicable, add screenshots/screencasts to help explain your problem.

System info

  • OS: Fedora 38, from git
  • Editor: VSCode
  • Version: git

Additional context
Add any other context about the problem here.

Weird COPR versioning

I was just looking at the Meson VSCode extension, as well as the COPR packages for Swift-MesonLSP, and I was initially confused why the extension is using version 3.0.5, while the COPR packages are only at version 0.0.34.

Then I realized that the Version and Release fields of the COPR packaging are backwards. As the Fedora Packaging Guidelines outline in the Versioning Guidelines section (emphasis added):

Fedora’s package versioning scheme encompasses both the Version: and Release: tags, as well as Epoch:. The overriding goal is to provide sequences of packages which are treated as updates by RPM’s version comparison algorithm while accommodating varied and often inconsistent upstream versioning schemes.

The Version: field contains the upstream project version, and the Release: field specifies the downstream release number.

Fortunately, since 3.0.5 is (much) higher than 0.0.34, version-comparison-wise, swapping the fields around and creating a Swift-MesonLSP-3.0.5-0.1.x86_64.rpm package would be no problem, as it would be parsed as an upgrade to any of the current 0.0.* packages.

Rewrite in C++

Using Swift was a cool idea, but it causes a lot of problems:

  • DX: Basically no tooling for Linux, small ecosystem for Linux, basically no community outside of Apple-Dev/Serverside.
  • Distribution: Huge binaries due to stdlib/Foundation
  • Performance: No LTO etc. possible outside of Apple OSs

This can be solved by C++:

  • DX: Huge community, great tools, excellent ecosystem
  • Distribution: Basically trivial due to a lot of other programs using C++ on Linux
  • Performance: LTO/PGO possible, manual memory usage

Changes:

Rust-MesonLSP --lsp [--stdio] # For starting language server
Rust-MesonLSP meson.build # For linting
Rust-MesonLSP meson.build --test # For testing using the testing framework
Rust-MesonLSP --wrap a.wrap b.wrap --wrap-output wo --wrap-package-files ./package-files/ # For downloading wrap files

Libraries to use:

  • libcurl for downloading files
  • libarchive for extracting tar.{xz,gz,bz2} and zip files
  • tree_sitter for tree-sitter
  • ??? for SHA256
  • libuuid for generating uuids
  • ??? for hg-wraps (Or just spawn hg?)
  • ??? for svn-wraps (Or just spawn svn?)

[Dec 2023] Port to ChimeHQ infrastructure

sourcekit-lsp isn't suitable for our use, unless Swift-MesonLSP pulls in parts of SPM, etc. due to transitive dependencies.

Switching has these advantages:

  • Probably smaller binary size => Lower compile times
  • Stable API
  • Easier to contribute

The port will start in December 2023 and is estimated to take a week

Requires ChimeHQ/LanguageServerProtocol#14 to be merged

libdrm meson causes SIGILL / auto-killed by vscode

Describe the bug

Trying to use the extension on the meson build configuration for libdrm, the extension goes into a crash-loop, see below:

[ INFO ] Downloading WrapDB data from https://wrapdb.mesonbuild.com/v2/releases.json
[ INFO ] Executing "'curl' 'https://wrapdb.mesonbuild.com/v2/releases.json' '-o' '/tmp/89B9C07E-3CD0-4BDC-AA80-194D42AA60EC' '-s' '-L'" at ???
[ INFO ] Connected with client Visual Studio Code 1.84.2
[ INFO ] Renaming is disabled as it is broken outside of GNOME Builder. Use GNOME Builder for an optimal experience.
[ INFO ] Swift-MesonLSP is licensed under the terms of the GNU General Public License v3.0
[ INFO ] Need help? - Open a discussion here: https://github.com/JCWasmx86/Swift-MesonLSP/discussions or join https://matrix.to/#/#mesonlsp:matrix.org
[ INFO ] No subprojects directory found
[ INFO ] Setup all directories for subprojects
[ INFO ] Setup all subprojects, rebuilding tree (If there were any found)
[Error - 9:30:26 AM] Server process exited with signal SIGILL.
[Error - 9:30:26 AM] The Meson Language Server (Swift-MesonLSP) server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

Part of earlier error context is this:

[ ERROR ] ResponseError(code: LanguageServerProtocol.ErrorCode(rawValue: -32601), message: "Unhandled method window/workDoneProgress/create")
...
[ ERROR ] Error during sleeping: CancellationError()
[ INFO ] Cancelling parsing - After sleeping
...
[ INFO ] Version = >= 0.59
[ INFO ] Publishing 3 diagnostics for /home/stefan/gitlab.freedesktop.org/mesa/drm/tests/tegra/meson.build
[ WARNING ] Unused assignment
[ WARNING ] Unused assignment
[ WARNING ] Unused assignment
...

I cannot tell whether tests/tegra/meson.build is part of the problem, or whether this is just the extension being unhappy with itself.

To Reproduce
Steps to reproduce the behavior:

  1. install extension into Visual Studio Code (latest == 1.84.2)
  2. git clone https://gitlab.freedesktop.org/mesa/drm
  3. open cloned repository in Visual Studio Code
  4. open tests/tegra/meson.build
  5. See error

Expected behavior
No SIGILL, no crash-loop.

System info

  • OS: Fedora Linux 39, x64_86, extension from Microsoft Marketplace
  • Editor: Visual Studio Code (latest == 1.84.2)
  • Version: mesonbuild.mesonbuild v1.18.1 (2023-11-17, 17:38:30)

Take `project(meson_version:)` into account when suggesting that APIs are deprecated

Meson's project() has a meson_version keyword argument that projects can use to indicate the minimum versions of Meson they support.

In the event that an API is deprecated in latest Meson, the language server warns about deprecated functions without evaluating whether the API is valid in the project(meson_version:) keyword argument.

It would be great if the language server could take this into account.

Can't resolve symbols coming from subdir if the path depends on cross-files if used in VSCode

Describe the bug
If the meson.build file contains a subdir(path) where path depends on some value coming from a cross file, the language server will not be able to resolve this symbol and therefore will flag the symbols as "Unknown Identifiers".

To Reproduce
Steps to reproduce the behavior:

  1. Clone https://github.com/danielefaugiana/auser
  2. Open the project in Visual Studio Code
  3. Check the top level Meson file, see the arch_src, arch_include and kernel_linker_script variables are flagged

Expected behavior
All symbols are resolved taking the information from the default build directory as set in Visual Studio Code's Meson Options.
The build directory contains the configuration information in meson-info so this information should be available.

Screenshots/Screencasts
image

System info

  • OS: Ubuntu 23.10, language server installed through Visual Studio Code
  • Editor: Visual Studio Code with Meson extension v1.12.1
  • Version: 1.83.1 (VSCode)

shell completion

Is your feature request related to a problem? Please describe.
Can it provide completions for common shells?

Describe the solution you'd like

$ mesonlsp --<TAB>

Both apple architecture zip archives in the releases section are invalid

Currently the apple darwin zip archives seem to be broken.

To Reproduce
Steps to reproduce the behavior:

  1. Download the archive, e.g. curl -OJ https://github.com/JCWasmx86/mesonlsp/releases/download/v4.1.8/mesonlsp-aarch64-apple-darwin.zip
  2. Attempt to unzip the archive unzip mesonlsp-aarch64-apple-darwin.zip
  3. See error:

End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of mesonlsp-aarch64-apple-darwin.zip or
mesonlsp-aarch64-apple-darwin.zip.zip, and cannot find mesonlsp-aarch64-apple-darwin.zip.ZIP
, period.

Expected behavior
I expect the unarchiving to work. To test I ran through exactly the same steps with the gnu-windows zip file and it worked fine, although obviously is useless on a Mac.

System info

  • OS: MacOS Ventura 13.6.4 M1 and Sonoma 14.4.1 x64

Additional context
Windows zip archive works as expected, only the Mac releases seem impacted. I also tested at least the aarch zip archive back to 4.1.2, all were affected.

[Catch-All Issue] More diagnostics

This is a catch-all issue for listing/brainstorming ideas for new diagnostics/checks.

Reassignment of loop variables

Disabled by default.

foreach xyz : some_list
  # ... some code ...
  xyz = 2 # Warning: Reassignment of loop variable
  # ... some more code ...
endforeach

Use of loop variable after loop

Disabled by default.

foreach xyz : some_list
  # ... code ...
endforeach

message(xyz) # Use of loop variable after loop

Github Actions need cleanup

Github Actions is currently an inefficient mess.

Linting

  • Is nearly perfect except the swift-format workflow. Sadly the docker image didn't work

Windows

  • Is simply really flaky

Build.yml

  • Probably won't work on PRs
  • Too much cloning.
  • Too much mess with the dockerfiles

The amount of uploaded files, etc. should stay the same

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.