-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
feat(language server): integrated new vfs #294
Conversation
Codecov Report
@@ Coverage Diff @@
## master #294 +/- ##
==========================================
- Coverage 79.54% 78.76% -0.78%
==========================================
Files 228 236 +8
Lines 13480 13866 +386
==========================================
+ Hits 10722 10922 +200
- Misses 2758 2944 +186
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed the first half of this change. In general it looks good, but I'm not sure why we need to move away from async
? Was that just easier to keep in line with RA?
Its not about performance but more about the general simplicity of the code. It also makes it easier to use some of the tools out there. A lot is not async (salsa being a big example). You can see currently there are a lot of block_ons in there for that reason. |
8ef71f4
to
8a6e9b4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still 2 large files left to review
8a6e9b4
to
d5592d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once you've incorporated these changes, feel free to merge.
/// Returns true if, according to this instance, the file at the given `path` is contained in | ||
/// this set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Returns true if, according to this instance, the file at the given `path` is contained in | |
/// this set. | |
/// Returns whether - according to this instance - the file at the given `path` is contained in | |
/// this set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think returns true if
is clearer. Do you want me to replace the commas with dashes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intend was to replace the "true if" as whether is the linguistic form of representing that. I always find it weird when people refer to a logical (or programmer) perspective of true
in sentences, such as in the documentation.
/// Returns true if, according to this instance, the directory at the given `path` is contained | ||
/// in this set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Returns true if, according to this instance, the directory at the given `path` is contained | |
/// in this set. | |
/// Returns whether - according to this instance - the directory at the given `path` is contained | |
/// in this set. |
self.includes_path(path) | ||
} | ||
|
||
/// Returns true if the given path is considered part of this set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Returns true if the given path is considered part of this set. | |
/// Returns whether the given path is considered part of this set. |
/// Returns true if, according to this instance, the file at the given `path` is contained in | ||
/// this entry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Returns true if, according to this instance, the file at the given `path` is contained in | |
/// this entry. | |
/// Returns whether - according to this instance - the file at the given `path` is contained in | |
/// this entry. |
/// Returns true if, according to this instance, the directory at the given `path` is contained | ||
/// in this set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Returns true if, according to this instance, the directory at the given `path` is contained | |
/// in this set. | |
/// Returns whether - according to this instance - the directory at the given `path` is contained | |
/// in this set. |
d5592d6
to
1a06e0f
Compare
This quite a large PR that drops the use
ra_vfs
and instead implements a custom solution based on the current solution in rust-analyzer but a tailored towards Mun.This also adds a new crate
mun_paths
that provides convenience structs for dealing with absolute and relative paths. SourceRoots have also been changed a bit. They now contain the relative paths to the files they contain instead of that being stored in the database. Since a single file might be contained in multiple source roots this makes more sense. I also introduced thePackageSet
to the database which holds all different packages that the database should know of.A lot of boilerplate around the language server is now consolidated which now also enables multiple mun packages in a single workspace.
I also hacked a bit around the use of async functions. Im planning to remove all async code and using a simple taskpool. I think async works really well for IO operations but for our computationally heavy usecase its easier to use threads. (did this in #295)
This PR also paves the way for much better testing of the language server because its now much easier to reason about the virtual filesystem and its progress (which was missing in the previous implementation). (similar to #293 )