schrieveslaach (1e7c703c) at 09 Dec 09:32

schrieveslaach (02c5d3ca) at 08 Dec 19:53

schrieveslaach (b1bfa8d7) at 08 Dec 19:33

... and 1 more commit

FYI, I've documentated the proxy configuration, see 9250c49c.

When you dont use connected mode, you have to explicitly enable all rules in config afaik. See #19

That is not 100% true. If you don't have any rules configuration in sonarlint.nvim, there are a set of rules loaded, but I don't know which logic is behind it. Once one starts using rules, only the ones in rules are loaded. If empty, none will be loaded and if no rules are enabled for the current language, you get no rules for that.

schrieveslaach (9250c49c) at 08 Dec 12:10

schrieveslaach (2f4d1b90) at 08 Dec 11:00

schrieveslaach (2f4d1b90) at 08 Dec 11:00

schrieveslaach (2f4d1b90) at 08 Dec 10:59

schrieveslaach (c0d97495) at 08 Dec 10:55

schrieveslaach (faddbf71) at 08 Dec 10:38

schrieveslaach (96c00823) at 08 Dec 10:28

schrieveslaach (99bc81d9) at 08 Dec 10:20

schrieveslaach (70b561b4) at 08 Dec 10:14

schrieveslaach (38c83a06) at 08 Dec 10:13

schrieveslaach (36f4fcee) at 01 Dec 09:40

@jeremieburtin, thank you very much for investing into this issue. @jeremieburtin, are you also working with a proxy or forced to use a proxy? If so, I would change the title of the issue.

After looking at the sources I decided to close this issue and don't implement this request.

To me this conventions is a local convention of the nvim-lspconfig plugin and not something that is pushed for across all LSP related plugins. Also, I don't see any activity related to this request in https://github.com/mrcjkb/rustaceanvim nor in https://codeberg.org/mfussenegger/nvim-jdtls.

As for the path to the compilation database I use the default one wich is ./compile_commands.json so I don't need to specify it explicitly.

Did you double check this statement? Looking at the sonarlint VSCode configuration spec, I see that they use an absolute path in the example:

Path to the active compilation database, e.g. `C:\\Repos\\MyProject\\compile_commands.json

Do you mind to provide a source definition of this conventions? I never heard of it and nvim-jdtls has no Lsp prefix in its commands.

@MKoseler, the config looks fine to me. Currently, the proxy might be an explanation why this is not working. Did you try if sonarlint for VScode works properly with setting up a connection? That would give us a good hint if it is related to a potential proxy issue or if it is due to some issue in sonarlint.nvim.

Also, you could try to debug sonarlint-language-server (if you are a Java dev) and see if you can find anything. Checkout this line in my dotfiles.

I guess, sonarlint-language-server fails because there is no analyzer present (checkout the -analyzers option). Also, for getting diagnostics for C, you need to specify the path to the compilation database (see here).

Java 17 should be fine.

schrieveslaach (ccf52586) at 06 Nov 12:17

Based on https://github.com/SonarSource/sonarlint-language-server/pull/551 this commit enhances the handler sonarlint/canShowMissingRequirementsNotification to check if the sonarlint-language-server supports the error_only return value to make sure that missing setup requirements will shown as LSP standard window message.

Fixes #29

schrieveslaach (0adb60a1) at 06 Nov 08:14

@jeremieburtin, are you certain that analyzers_path .."sonarjs.jar", points to correct path?

@mrt181, I see in your config that you enbaled sonarlint.nvim for CS only:

      filetypes = { "cs" },

Please, try with the additional file types.

I see rules = vim.empty_dict() in your LSP config. Can you remove it because look at the sonarlint.nvim README:

Rules can be configured, e.g. by turning them on or off, with the following configuration. Please note that rules = {} deactivates all rules.

Can you check following questions?

• Do you get a pop up in Neovim after changing the line locally?
• Can you tell me which sonarlint-language-server version you are using?
• Is there any error or suspicious message in :LspLog?

schrieveslaach (46a8007d) at 20 Oct 20:06

FYI: new attempt to fix it upstream, see https://github.com/SonarSource/sonarlint-language-server/pull/548

Can you try to adjust following code locally in your local sonarlint.nvim?

   config.handlers["sonarlint/canShowMissingRequirementsNotification"] = function()
      return true
   end

I think sonarlint.nvim swallows the notification. Meanwhile, I tried to improve upstream so that you get a proper message in Neovim.

4.3.1 should now be working without the custom init options. @coderkun, do you mind to try it without custom init options?

Cool, thanks for testing.

schrieveslaach (9ce2318b) at 04 Oct 10:09

When I use the new setup method via lspconfig then I get the error below.

https://github.com/mfussenegger/nvim-jdtls/?tab=readme-ov-file#via-lspconfig

Error executing vim.schedule lua callback: ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: attempt to index field 'handl
ers' (a nil value)                                                                                                                       
stack traceback:                                                                                                                         
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: in function 'init_config'                                       
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:166: in function ''                                                  
        vim/_editor.lua: in function ''                                                                                                  
        vim/_editor.lua: in function <vim/_editor.lua:0>                                                                                 

I couldn't figure out how to delay or postpone sonarlint configuration after the nvim-jdtls has done it's init setup.

schrieveslaach (1d49a469) at 04 Oct 10:09

Fixes #36

schrieveslaach (e6b8ac4d) at 03 Oct 10:19

After changing my dotfiles to use also the new jdtls initialization, I could reproduce your recent error. Now, it should be working fine. Can you give it another try?

schrieveslaach (9ce2318b) at 03 Oct 10:07

I found another approach that's get rid of the dependency on language/status. Do you mind to check if this is working with new jdtls setup. With the old setup it works.

schrieveslaach (0eda4467) at 02 Oct 10:06

@azdanov, can you try !27 (merged) to see it that fixes the issue?

Fixes #36

schrieveslaach (12a749c8) at 30 Sep 11:17

schrieveslaach (6a3f95e0) at 30 Sep 11:10

schrieveslaach (eb3d9c16) at 30 Sep 11:08

schrieveslaach (7feaa7ad) at 28 Sep 11:01

schrieveslaach (1281dbb4) at 28 Sep 10:57

Yes, that could be done to prevent the crashing. What bothers me though, that a client can crash the server and currently sonarlint-language-server relies on the client to not crash the server (see also my comment here).

Let's see how they respond.

Meanwhile, you should be able to prevent the crash in your local sonarlint.nvim conf:

         require("sonarlint").setup({
            server = {
               -- …
               init_options = {
                  connections = vim.empty_dict(),
                  rules = vim.empty_dict(),
                  automaticAnalysis = true,
               },
            },
         })

FYI: https://github.com/SonarSource/sonarlint-language-server/pull/532

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..b8a76ef6 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -31,7 +32,7 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> additionalAttributes,
   String clientNodePath,
   boolean focusOnNewCode,
-  boolean automaticAnalysis,
+  Boolean automaticAnalysis,
   String omnisharpDirectory,
   String csharpOssPath,
   String csharpEnterprisePath,
@@ -41,4 +42,16 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+  public SonarLintLanguageServerInitializationOptions {
+    if (rules == null) {
+      rules = Collections.emptyMap();
+    }
+    if (connections == null) {
+      connections = Collections.emptyMap();
+    }
+    if (automaticAnalysis == null) {
+      automaticAnalysis = Boolean.TRUE;
+    }
+  }
+
 }

This change did the trick. Digging into the diff of the release revealed to me that sonarlint-language-server relies on the client to initialize some maps. I'll create a PR and see if they'll merge it.

I can confirm that I'm running into the same issue. I created a fix for the NPE locally and tried to see if that is enough and if this local fix could be upstreamed. Here is the fix:

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..3a797b72 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -41,4 +42,13 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+   public SonarLintLanguageServerInitializationOptions {
+      if (rules == null) {
+         rules = Collections.emptyMap();
+      }
+      if (connections == null) {
+         connections = Collections.emptyMap();
+      }
+   }
+
 }

That fixes the error message and the LSP starts. However, there must be more adjustment because I don't get any diagnostics from Sonarlint LS.

schrieveslaach (29ae9ff6) at 18 Sep 06:28

schrieveslaach (067f041f) at 18 Sep 06:14

schrieveslaach (dc570255) at 18 Sep 06:14

With this commit the rule description is converted from HTML to markdown so that the display in the UI looks nicer.