Closed bananastalktome closed 3 months ago
Thank you for the bug report! For the time being, downgrading the extension to v0.7.10 should bring back the old behaviour - since it does not register the extension for handling ERB files.
Are you positive the issue is with solargraph being in the Gemfile, though? The Ruby LSP is its own independent Ruby process and we don't require solargraph, so I can't immediately see how it being in the Gemfile would impact ERB functionality.
@vinistock, downgrading the extension to v0.7.10
works 👍
FWIW, I am having this same problem, and my project does not use solargraph.
@vinistock Solargraph being in the Gemfile
was the way I found I was able to replicate the behavior, but it could be coincidence (as @shanebonham notes, they have the same issue without solargraph present). v0.7.10 does work in the meantime though.
With the current extension version, in the VS Code footer at the bottom right, is it showing ERB
or Ruby
as the file type?
For both 0.7.10
and 0.7.11
, it shows as erb
.
@andyw8 For me it shows as Ruby ERB
in the bottom right for 0.7.10
and 0.7.11
We don't even show diagnostics for ERB files (we return early).
I think this is what's happening: we define erb as the language ID with our grammar file associated to it.
Any a file doesn't match the erb
language ID, we default to considering it a Ruby file (which then explains why you're seeing diagnostics).
I believe that can only happen if another extension or your VS Code settings are associating a different language ID to ERB files.
Do any of you have any other Ruby VS Code extensions or the following setting?
{
// Your JSON settings
"files.associations": {
// If you switch the language ID of ERB files to another one, there will be a mismatch
// in the server
"*.erb": "Ruby ERB"
}
}
Found this issue after running into the same issue with erb file. Reverting to an older version worked. The file is listed as erb
and my settings don't have any associations for *.erb
@vinistock I did have craigmaslowski.erb
and aliariff.vscode-erb-beautify
, but even after disabling them & restarting VSCode completely, I still get the problem behavior with 0.7.11
(though now my language shows erb
just like in https://github.com/Shopify/ruby-lsp/issues/2282#issuecomment-2221211980). I don't define that files.associations
*.erb
key anywhere.
Edit: In the VSCode developer tools 'element' view, the editor instance data-mode-id is set properly to erb
:
.
If you turn on verbose tracing for the server:
// Settings.json
{
"ruby lsp.trace.server": "verbose"
}
All requests and their parameters get printed to the Ruby LSP
channel in the Output
tab. When you open an ERB file, the textDocument/didOpen
request should have the languageId
parameter set to erb
.
If that's not the case, something is changing the language ID of ERB files. It could be a user setting, a workspace setting (.vscode/setings.json), a different extension. We need to understand what is changing the language ID.
@vinistock Got the trace (after a scary amount of output):
2024-07-10 15:33:44.818 [info] (project) [Trace - 3:33:44 PM] Sending notification 'textDocument/didOpen'.
2024-07-10 15:33:44.818 [info] (project) Params: {
"textDocument": {
"uri": "file:///Users/<REDACTED>file.html.erb",
"languageId": "erb",
"version": 1,
"text": "<REDACTED>"
}
}
@vinistock If it helps, here is the full output when opening a simple file:
2024-07-10 15:37:05.244 [info] (project) [Trace - 3:37:05 PM] Sending notification 'textDocument/didOpen'.
2024-07-10 15:37:05.244 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb",
"languageId": "erb",
"version": 1,
"text": "<h1 class=\"text-4xl font-bold\">404: Not Found</h1>\n<%= render partial: \"errors/exception\", locals: { exception: local_assigns[:exception] } %>\n"
}
}
2024-07-10 15:37:05.244 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/diagnostic - (83)'.
2024-07-10 15:37:05.244 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.245 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/diagnostic - (83)' in 1ms.
2024-07-10 15:37:05.245 [info] (project) Result: {
"kind": "full",
"items": [
{
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 0,
"character": 1
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected '<', ignoring it"
},
{
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 9
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected constant path after `class`; class/module name must be CONSTANT"
},
{
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 9
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected constant path after `class`; class/module name must be CONSTANT"
},
{
"range": {
"start": {
"line": 0,
"character": 9
},
"end": {
"line": 0,
"character": 10
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected '=', ignoring it"
},
{
"range": {
"start": {
"line": 0,
"character": 34
},
"end": {
"line": 0,
"character": 35
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected ':', expecting end-of-input"
},
{
"range": {
"start": {
"line": 0,
"character": 34
},
"end": {
"line": 0,
"character": 35
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected ':', ignoring it"
},
{
"range": {
"start": {
"line": 1,
"character": 27
},
"end": {
"line": 1,
"character": 37
}
},
"severity": 1,
"source": "Prism",
"message": "unknown regexp options: cpt"
},
{
"range": {
"start": {
"line": 1,
"character": 37
},
"end": {
"line": 1,
"character": 38
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected string literal, expecting end-of-input"
},
{
"range": {
"start": {
"line": 2,
"character": 0
},
"end": {
"line": 2,
"character": 0
}
},
"severity": 1,
"source": "Prism",
"message": "unterminated string meets end of file"
},
{
"range": {
"start": {
"line": 2,
"character": 0
},
"end": {
"line": 2,
"character": 0
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected end of file, expecting end-of-input"
},
{
"range": {
"start": {
"line": 2,
"character": 0
},
"end": {
"line": 2,
"character": 0
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected end of file, assuming it is closing the parent top level context"
},
{
"range": {
"start": {
"line": 2,
"character": 0
},
"end": {
"line": 2,
"character": 0
}
},
"severity": 1,
"source": "Prism",
"message": "expected an `end` to close the `class` statement"
},
{
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 9
}
},
"severity": 1,
"source": "Prism",
"message": "unexpected constant path after `class`; class/module name must be CONSTANT"
},
{
"range": {
"start": {
"line": 0,
"character": 10
},
"end": {
"line": 0,
"character": 34
}
},
"severity": 2,
"source": "Prism",
"message": "possibly useless use of > in void context"
},
{
"range": {
"start": {
"line": 1,
"character": 37
},
"end": {
"line": 2,
"character": 0
}
},
"severity": 2,
"source": "Prism",
"message": "possibly useless use of a literal in void context"
}
]
}
2024-07-10 15:37:05.246 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/codeAction - (84)'.
2024-07-10 15:37:05.247 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
},
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 0,
"character": 0
}
},
"context": {
"diagnostics": [
{
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 0,
"character": 1
}
},
"message": "unexpected '<', ignoring it",
"severity": 1,
"source": "Prism"
}
],
"triggerKind": 2
}
}
2024-07-10 15:37:05.249 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/documentSymbol - (85)'.
2024-07-10 15:37:05.249 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.249 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/codeAction - (84)' in 3ms.
2024-07-10 15:37:05.249 [info] (project) Result: []
2024-07-10 15:37:05.249 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/documentSymbol - (85)' in 0ms.
2024-07-10 15:37:05.250 [info] (project) Result: [
{
"name": "class",
"kind": 5,
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 2,
"character": 0
}
},
"selectionRange": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 9
}
},
"children": []
}
]
2024-07-10 15:37:05.252 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/documentLink - (86)'.
2024-07-10 15:37:05.252 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.252 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/inlayHint - (87)'.
2024-07-10 15:37:05.252 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
},
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 2,
"character": 0
}
}
}
2024-07-10 15:37:05.252 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/documentLink - (86)' in 0ms.
2024-07-10 15:37:05.252 [info] (project) Result: []
2024-07-10 15:37:05.252 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/inlayHint - (87)' in 0ms.
2024-07-10 15:37:05.252 [info] (project) Result: []
2024-07-10 15:37:05.447 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/foldingRange - (88)'.
2024-07-10 15:37:05.447 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.448 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/foldingRange - (88)' in 1ms.
2024-07-10 15:37:05.448 [info] (project) Result: [
{
"startLine": 0,
"endLine": 1,
"kind": "region"
},
{
"startLine": 0,
"endLine": 1,
"kind": "region"
}
]
2024-07-10 15:37:05.498 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/codeLens - (89)'.
2024-07-10 15:37:05.498 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.498 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/codeLens - (89)' in 0ms.
2024-07-10 15:37:05.498 [info] (project) Result: []
2024-07-10 15:37:05.516 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/codeAction - (90)'.
2024-07-10 15:37:05.516 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
},
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 0,
"character": 0
}
},
"context": {
"diagnostics": [
{
"range": {
"start": {
"line": 0,
"character": 0
},
"end": {
"line": 0,
"character": 1
}
},
"message": "unexpected '<', ignoring it",
"severity": 1,
"source": "Prism"
}
],
"triggerKind": 2
}
}
2024-07-10 15:37:05.517 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/codeAction - (90)' in 1ms.
2024-07-10 15:37:05.517 [info] (project) Result: []
2024-07-10 15:37:05.547 [info] (project) [Trace - 3:37:05 PM] Sending request 'textDocument/documentSymbol - (91)'.
2024-07-10 15:37:05.547 [info] (project) Params: {
"textDocument": {
"uri": "file:///<REDACTED>/app/views/errors/not_found.html.erb"
}
}
2024-07-10 15:37:05.548 [info] (project) [Trace - 3:37:05 PM] Received response 'textDocument/documentSymbol - (91)' in 1ms.
2024-07-10 15:37:05.548 [info] (project) Result: [
{
"name": "class",
"kind": 5,
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 2,
"character": 0
}
},
"selectionRange": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 9
}
},
"children": []
}
]
So, the language ID is correct. Oh, maybe the server is outdated? If you do
Does that fix the issue?
@vinistock I ran that server gem update VSCode command, but that didn't fix the issue either, unfortunately.
If you click on the language status item (the {}
next to Ruby here), what server version are you on?
huh, weird Not the latest (should be 0.17.6 I guess) even though I did run the update command through VSCode
Okay. That makes sense, the server isn't able to handle ERB files.
Usually, when it fails to upgrade, it's because your project is locked to an older version of prism
or sorbet-runtime
, which then stops Bundler from updating the LSP.
You can try it on the terminal with
BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle update ruby-lsp
humm, Bundler attempted to update ruby-lsp but its version stayed the same
. I had to manually add gem "ruby-lsp", "0.17.6"
to my project Gemfile
(not ideal, but it worked) in order to update to the latest version, and then erb mode works. I'd rather not pin the ruby-lsp version in my Gemfile, it's weird that it wouldn't update when I ran the command even in the basic Gemfile reproduction setup (with only solargraph
listed).
It could be the rbs
dependency that is restricting it as well. Solargraph also depends on RBS, so if it's locked to anything older than 3, the Ruby LSP won't update.
Updating the server fixed it for me; thanks for the fast responses.
In case it's not a pain to implement, detecting a minimum server version with the extension would be have been a better error to encounter than the parsing output.
@LucasKuhn that won't work in the long term. The next time you upgrade any gem in the application, the Ruby LSP will overwrite the custom lockfile again and you'll end up in the same scenario again.
Check if prism
, sorbet-runtime
or rbs
are locked in the Gemfile.lock of the app and upgrade those.
Thank you @vinistock! Deleted my suggestion to avoid confusion.
For me it was indeed rbs
, required by solargraph.
solargraph is currently pinned to rbs ~> 2.0
. There's a PR to update from more a year ago but its not gotten merged yet.
Ran into this issue tonight,I noticed I still had an old version of solargraph listed in my development group despite not using that extension anymore:
gem 'solargraph', '~> 0.49.0'
Removing this gem worked -- not a great solution if you use solargraph but if you don't and have the gem just remove it to resolve the issue.
Removing solargraph
also solved this for me.
Thanks for suggestion @vinistock Downgrading to v0.7.10
worked for me. Hope this gets fixed 🤞
What are your reasons for keeping solargraph around still? With https://gist.github.com/castwide/28b349566a223dfb439a337aea29713e and the solargraph-rails
extension it does still offer better rails support (I think), just has better insight into the metaprogramming. I'm curious if that is part of your reasoning, or if its something else. The fix from the solargraph side would be https://github.com/castwide/solargraph/pull/662.
FWIW, my problem was that I'm getting ruby-lsp via the ruby-lsp-rails gem (ruby-lsp-rails is the only thing my Gemfile), so trying to bundle update ruby-lsp
was not getting me to the latest version. Had to bundle update ruby-lsp-rails
to unjam the bundles.
@hayesr you don't need ruby-lsp-rails in your Gemfile any more, ruby-lsp will automatically enable it when it detects a Rails app. Removing it should help with keeping things up-to-date.
@andyw8 Ok that's helpful, thanks!
@nikasvan I don't believe downgrading is an optimal solution. I suggested that while we were still understanding the issue. But it goes beyond not having errors for ERB files.
If you are unable to upgrade the server gem, you will not have access to any new features we ship. Almost all features in a language server are implemented in the server and not on the client side.
For example, if you can't upgrade past v0.17.2, you are currently missing out on:
super
in go to definition and hoverPlus whatever we ship in the next versions until the constraint is lifted and you can successfully upgrade the ruby-lsp
gem.
Even if we came up with a way to avoid the errors for ERB, being unable to upgrade the language server gem is incompatible with delivering a good developer experience. We need to be able to get new features into the hands of developers. Bugfixes. Performance improvements. And the quicker we can do that, the better.
Thanks for digging into this @vinistock and everybody else.
For our project, it's another gem prawn-manual_builder
that is locking the version of prism
at 0.22.0
. I've raised the issue with them.
I was having the same issue and, after reading this issue start to finish, these were the steps:
solargraph
and ruby-lsp-rails
from gemfile;bundle
;Ruby LSP: update language server gem
;{ }
icon in the bottom right corner of vscode and confirming Ruby LSP server is version >= 0.17.7This solved the ERB issue and the code navigation kept working!
Thanks a lot for the work on this great DX tool.
I created a proposal of a possible way to mitigate the issue https://github.com/Shopify/ruby-lsp/pull/2311.
At the root of the problem is the fact that some users cannot update the server gem, which means pushing a fix in the server is useless (they wouldn't be able to upgrade to the version with the bug fix anyway).
However, trying to fix this from the extension side isn't trivial either. The document selector, which dictates the file types handled by the language server, has to be informed as part of the client options before trying to spawn the language server. But it's not possible to know which version of the server gem will be installed for a project without first trying to boot it (there's no way to know which version Bundler will resolve to before we actually launch).
Mutating the document selector after boot has no effect whatsoever. After the client has been launched with one document selector, it will continue to serve requests for all of the included file types.
This means that the only possible workaround is to perform a full restart of the client if we identify that it does not have support for handling ERB files.
Anyone running an old server version would need to launch the server twice every single time (which means running indexing twice as well), until they are able to upgrade the gem.
Alternatively, we could also just print a warning linking to this issue and explaining what's wrong, but not automatically restart the client - but then the ERB issues will not go away.
Frankly, none of the options are great and it kind of circles back to my previous point: there's no way to deliver a good developer experience if people can't use the latest versions of the server.
Alternatively, we could also just print a warning linking to this issue and explaining what's wrong, but not automatically restart the client - but then the ERB issues will not go away.
This seems preferable to me, since it gives more of an opportunity to explain the problem to users.
I really disliked the double-launch approach, so we ended up providing the ability to disable ERB support through a setting https://github.com/Shopify/ruby-lsp/pull/2311.
The reason is because another dependency's constraints are blocking updates for the ruby-lsp
gem. You should look for other gems that depend on rbs
, prism
or sorbet-runtime
and try to ensure they are up to date.
Not being able to upgrade the language server is troublesome and the optimal solution is to figure out why the upgrades are failing and then fix it. Read the rest of the issue for more context.
Turn off ERB support until you are able to upgrade the ruby-lsp
gem.
// Your VS Code settings
{
"rubyLsp.erbSupport": false
}
Note: this setting is a temporary escape hatch. We will not support old versions of the language server indefinitely. After a few months of allowing users to turn off ERB support, we will remove the setting and go back to turning on support for all users.
Updated to the latest version and added "rubyLsp.erbSupport": false
but I still have the issue.
We haven't cut a release that includes the PR adding the setting yet.
Okay. That makes sense, the server isn't able to handle ERB files.
Usually, when it fails to upgrade, it's because your project is locked to an older version of
prism
orsorbet-runtime
, which then stops Bundler from updating the LSP.You can try it on the terminal with
BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle update ruby-lsp
That solves it to me
I removed Gemfile.lock
and ran bundle install
again. Only then did it disappear for me.
"rubyLsp.erbSupport": false,
worked for me!
Updating ruby-lsp
gem to 0.17.17
and prism
to 1.0.0
worked for me
I had the same issue. Removed rufo & solargraph from Gemfile, bundle install. Problem solved, thanks for hints
I had the same issue. Removed rufo & solargraph from Gemfile, bundle install. Problem solved, thanks for hints
Yes, that was all I needed to do. I didn't have rufo
in my Gemfile, but I did have Solargraph. I removed it, did bundle i
and now that formatting madness has gone away!
Description
Description
The latest Ruby LSP VSCode extension (v0.7.11) generates numerous code problems for ERB files which should not be indicated as problems. The issue does not occur with v0.7.10. I've attached two screenshots - one of the code:
and another of the 'Problems' output:
I think I narrowed it down to it only occurring when the
solargraph
gem is installed from myGemfile
, but the odd behavior occurs whether the VSCode "castwide.solargraph" extension is enabled or not (even occurs with thesolargraph
gem present when the "castwide.solargraph" extension has been fully uninstalled).To Reproduce
.ruby-version
containing an rbenv ruby version (3.2.2 in my case)Gemfile
containing onlygem "solargraph", require: false
test.html.erb
file with any valid HTMLbundle install
and then open VSCode in that directorytest.html.erb
file once the LSP extension starts the language server