emacs-lsp / lsp-java

lsp-mode :heart: java
https://emacs-lsp.github.io/lsp-java
GNU General Public License v3.0
642 stars 89 forks source link

Multi-line Strings Break lsp-execute-code-action #424

Open JoshTRN opened 1 year ago

JoshTRN commented 1 year ago

Describe the bug Multi-line String literals completely breaks lsp code actions.

To Reproduce

  1. Create an example directory.

  2. Inside create a Main.java file.

  3. Inside Main.java create the following Main class.

    class Main {
    List<Object> l = new ArrayList<Object>();
    }
  4. Call lsp-execute-code-action, import the dependencies and notice the code actions still working.

  5. Remove the imported objects and Create a multiline String. Your file should now look like this:

    class Main {
    List<Object> l = new ArrayList<Object>();
    String s = """
      hello
      """;
    }
  6. Attempt to lsp-execute-code-action once again.

From here, you'll see an error message in the mini buffer and messages buffer similar to the following:

c-clear-string-fences: Args out of range: #<marker (moves after insertion) at 131 in Main.java>, #<marker (moves after insertion) at 131 in Main.java>

Expected behavior Emacs should populate the missing objects like normal.

Logs I think this is purely a client error as there are no lsp errors, but errors generated by emacs.

Work-Around

Comment out all the multiline strings and revert the buffer. You will now be able to execute code actions once again.

JoshTRN commented 1 year ago

This is the emacs debug on error log:

Debugger entered--Lisp error: (args-out-of-range #<marker (moves after insertion) at 131 in Main.java> #<marker (moves after insertion) at 131 in Main.java>)
  get-text-property(#<marker (moves after insertion) at 131 in Main.java> c-fl-syn-tab)
  c-restore-string-fences()
  c-before-change(1 1)
  run-hook-with-args(c-before-change 1 1)
  lsp--apply-text-edit-replace-buffer-contents(#<hash-table equal 2/2 0x157dd3feff4b>)
  #f(compiled-function (edit) #<bytecode 0x178c628089537d10>)(#<hash-table equal 2/2 0x157dd3feff4b>)
  mapc(#f(compiled-function (edit) #<bytecode 0x178c628089537d10>) [#<hash-table equal 2/2 0x157dd3feff4b>])
  lsp--apply-text-edits([#<hash-table equal 2/2 0x157dd3feff4b>] code-action)
  lsp--apply-text-document-edit(#<hash-table equal 2/2 0x157dd3fe19d9> code-action)
  #f(compiled-function (change) #<bytecode -0x1d95d7e85e762909>)(#<hash-table equal 2/2 0x157dd3fe19d9>)
  mapc(#f(compiled-function (change) #<bytecode -0x1d95d7e85e762909>) (#<hash-table equal 2/2 0x157dd3fe19d9>))
  seq-do(#f(compiled-function (change) #<bytecode -0x1d95d7e85e762909>) (#<hash-table equal 2/2 0x157dd3fe19d9>))
  lsp--apply-workspace-edit(#<hash-table equal 2/2 0x157dd3fe1959> code-action)
  lsp--execute-code-action(#<hash-table equal 4/4 0x157dd3fe1645>)
  lsp-execute-code-action(#<hash-table equal 4/4 0x157dd5809051>)
  funcall-interactively(lsp-execute-code-action #<hash-table equal 4/4 0x157dd5809051>)
  call-interactively(lsp-execute-code-action nil nil)
  command-execute(lsp-execute-code-action)
yyoncho commented 1 year ago

This looks like emacs bug.