Start separating RubyDocument
and Document
concerns
#2222
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
First step towards #1206
I've been reflecting on what would be necessary to better support other document types in the Ruby LSP (e.g.: ERB, RBS, Slim, etc).
There are many parts of the codebase that will need a bit of restructuring to ensure we are separating concerns in a way that's manageable.
To begin, I'd like to propose a refactor to documents. Currently, the
Document
class has a lot of Ruby related logic baked in. For example, it assumes that Prism results are going to be available, which does not make sense for a document parsed with RBS or an ERB parser.This
Document
parent class should only house basic document functionality, like handling edits, locating a specific position in the source code (not nodes as those are document specific) and caching.Implementation
To begin the work of decoupling
RubyDocument
andDocument
, I have done these 3 (in the order of commits):comments
method. This is specific to the Prism implementation and cannot be generalized for all types of documents. For example, RBS attaches comments to specific declaration objects. Whenever we need the comments, we can just doprism_result.comments
tree
method. This is also Prism specific because theparse
method returns aParseResult
object. This is again not the case for RBS, which returns an array of declarations. We can also just invokevalue
on the parse result where neededsyntax_error?
an abstract method. Each document type will need to define how they track if there's a syntax errorNext steps
To fully support multiple document types in the LSP, we will need to:
Document
a generic class, where the type argument represents the AST that gets returned when we invoke the abstract methodparse
locate
andlocate_node
toRubyDocument
as those are specific to the Prism AST