Skip to content

Code causes syntax tree to crash #160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vwall opened this issue Sep 22, 2022 · 5 comments · Fixed by #162
Closed

Code causes syntax tree to crash #160

vwall opened this issue Sep 22, 2022 · 5 comments · Fixed by #162

Comments

@vwall
Copy link

vwall commented Sep 22, 2022

Looking at this issue #129 and it seems to work correctly from the CLI

example code:

LongRecordName.transaction do
  LongRecordName
    .joins(:other_record)
    # rubocop:disable Rails/SkipsModelValidations

    .update_all(foo: 'bar')
end

CLI:

Error: Cannot find expected end
> 1 | LongRecordName.transaction do
    |                            ^
  2 |   LongRecordName
  3 |     .joins(:other_record)
  4 |     # rubocop:disable Rails/SkipsModelValidations
The listed files did not match the expected format.

However in vscode it crashes synax-tree and there is nothing indicating that something is wrong. Is this the correct behavior?

VSCODE:

/Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree/parser.rb:251:in `find_token': Cannot find expected end (SyntaxTree::Parser::ParseError)
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree/parser.rb:1242:in `on_do_block'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree.rb:47:in `parse'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree.rb:47:in `parse'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree.rb:54:in `format'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree/language_server.rb:90:in `format'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree/language_server.rb:59:in `run'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/lib/syntax_tree/cli.rb:410:in `run'
	from /Users/nix/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/syntax_tree-3.6.0/exe/stree:9:in `<top (required)>'
	from /Users/nix/.asdf/installs/ruby/3.1.2/bin/stree:25:in `load'
	from /Users/nix/.asdf/installs/ruby/3.1.2/bin/stree:25:in `<main>'
[Info  - 5:29:20 PM] Connection to server got closed. Server will restart.
@kddnewton
Copy link
Member

Yeah we could definitely improve the user experience here. I think honestly if it fails to parse it should just not try to format.

Want to take a crack at improving this behavior? It would involve fixing it here:

contents = store[uri]
write(id: id, result: contents ? [format(store[uri], uri.split(".").last)] : nil)
.

@kddnewton kddnewton transferred this issue from ruby-syntax-tree/vscode-syntax-tree Sep 22, 2022
@vwall
Copy link
Author

vwall commented Sep 22, 2022

It seemed like vscode-prettier handled this sort of stuff well. SyntaxTree crashes on any syntax error with no UI warning. Even simple things like this crash it instead of fixing. Is this the intended behavior?

has_many :steps through: :user_topics

@kddnewton
Copy link
Member

No, the intended behavior is to not have it crash when there's a syntax error. Would you be able to attempt a PR? It would involve handling the parser error on that line I linked.

@vwall
Copy link
Author

vwall commented Sep 22, 2022

I guess i'm missing this answer. Is the purpose of syntax tree to show the error too in vscode, or to try and fix it first? I would assume on syntax error it would try to format and fix? Sorry for all the questions.

@kddnewton
Copy link
Member

Syntax Tree can't recover from syntax errors because the underlying CRuby parser isn't error tolerant. It has no knowledge of how to fix those things.

In VSCode I haven't made any effort to show the error as well. At the moment that's beyond the scope of this plugin. I'd be happy to support it if you want to put up a PR, but my efforts are elsewhere at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants