search

mesonbuild / vscode-meson

Meson for VisualStudio Code
Apache License 2.0
105 stars 51 forks source link

[Feature] Integrate language server #119

Open JCWasmx86 opened 1 year ago

JCWasmx86 commented 1 year ago

I wrote a language server for meson: https://github.com/JCWasmx86/Swift-MesonLSP (GPLv3, but currently trivially changeable as I'm the only contributor)

This is a tracking issue for integration in this extension.

Requirements

Runtime dependencies

Open questions

I made a fork of vscode-meson for testing: https://github.com/JCWasmx86/vscode-meson

dcbaker commented 1 year ago

I'll write a nix expression so we can test the distro packaged aproach

JCWasmx86 commented 1 year ago

I've setup a COPR for Fedora 37, here: https://copr.fedorainfracloud.org/coprs/jcwasmx86/Swift-MesonLSP/

JCWasmx86 commented 1 year ago

An APT Repo for Ubuntu 18.04/20.04/22.04 and Debian Stable/Testing/Unstable is set up here: https://github.com/JCWasmx86/swift-mesonlsp-apt-repo

JCWasmx86 commented 1 year ago

While #123 is probably in the last 10% before merging, here is some other stuff that has to be done after merging.

{
  "Swift-MesonLSP": {
    "versions": [
      {
        "number": "2.2",
        "diff": "https://link/to/diff/of/previous/version",
        "downloads": {
          "win32-x64": {
            "url": "https://...",
            "hash": "12345"
          },
          "darwin-x64": {
            "url": "https://...",
            "hash": "12345"
          }
        }
      }
    ]
  }
}

Updating would require that at one person merges a PR that updates the file. While auditing it to 100% is impossible, some basic checks for malicious code could be inserted there, albeit that would require effort you can't expect from volunteers. And obviously A can't review an update for the language server by A, as otherwise this entire construct would be pointless.

I'm not sure what your threat model is, but I think it auto-updating functionality (Or even just updating using a dialog "There is an update available, do you want to install it?") needs to consider security at some point.

(Or maybe I'm thinking a bit too much about it)

tristan957 commented 1 year ago

Perhaps this document should just be part of the extension. I don't really see why it couldn't.

I think we should stand on the shoulders of giants in this regard. I haven't looked at how it works, but the clangd extension has pretty good update functionality.

JCWasmx86 commented 1 year ago

Yes, makes sense. But if the JSON file is in the extension, it couples the language server to the extension version. But I will implement it in some next PR (Expect it sometime in the next five weeks)

tristan957 commented 1 year ago

I don't really think that is a big deal if I am being honest. Maybe @dcbaker has a different opinion.

JCWasmx86 commented 11 months ago

Now post-release there are these issues left:

Somewhat easy

Complicated

JCWasmx86 commented 11 months ago

There is now server-side support for configs. It requires the configuration to be sent using the didChangeConfiguration notification with this JSON:

{
  "others": {
    "ignoreDiagnosticsFromSubprojects": true/false/["subproj1", "subproj2"], // If true, don't show any diagnostics from subprojects, if false show all diags from subprojects, if it is an array of strings, these are excluded from the diagnostics
    "neverDownloadAutomatically": true/false // Disables wrap/subproject downloads (Not implemented yet), requested by xclaesse
  },
  "linting": {
    "disableNameLinting": true/false, // Disables checks for snake_case as requested by bruchar1
    "disableAllIdLinting": true/false, // Shortcut for all the following options
    "disableCompilerIdLinting": true/false // Disable checks, whether the string compared to compiler.get_id() is known
   "disableCompilerArgumentIdLinting": true/false,
   "disableLinkerIdLinting": true/false,
   "disableCpuFamilyLinting": true/false,
   "disableOsFamilyLinting": true/false,
  }
}
JCWasmx86 commented 7 months ago

Over the past few moths, I have rewritten Swift-MesonLSP in C++ (Now called mesonlsp): https://github.com/JCWasmx86/Swift-MesonLSP/pull/36 While it is not 100% finished yet, I wanted to outline the relevant changes:

Miscellaneous

Config Options

Potential future for LSP in vscode-meson (My ideas)

Thoughts of implementing something that encourages user feedback

My biggest problem is, that I basically have no feedback from the users. I asked once e.g. in the matrix channel for feedback, no responses. I'm basically in flying blind with e.g. requested features, bugs found, potential improvement ideas. I'm not sure how to solve this in a manner that is respectful to the user (==Absolutely no unwanted network connection, I'm absolutely against telemetry, and it's too much legal headache) and allows me to get user feedback.

Swift-MesonLSP 3.1.3 has 7k downlads, so let's say 6.5k users. I basically get continuous feedback from one person, I got maybe 3-4 issues with bugs/feature requests, so basically I have no idea what people want.

siberianbot commented 1 month ago

If I understood correctly, mesonlsp have --path parameter, which defines which file to parse as root. It will be very useful to specify path to root meson.build through VS Code settings.

I.e. my monorepo setup have several projects with different languages/build systems involved. mesonlsp looks for meson.build in root directory of workspace and I see such error messages in log:

[ WARN ] analyze::mesontree - ../src/libanalyze/mesontree.cpp:195: No meson.build file in {root directory name here}
JCWasmx86 commented 1 month ago

Theoretically a client could send a set of workspaceFolders (E.g. for the main project and one workspace folder for each subproject) to the language server, but that's currently not supported in this VSCode extension I think.

Maybe this could help temporarily: https://code.visualstudio.com/docs/editor/multi-root-workspaces But in the long-term it would be nice to have some property like paths that are a list of paths to send as workspace folder