-
-
Notifications
You must be signed in to change notification settings - Fork 648
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
[display] dynamically update the syntax cache #8451
Comments
This requires some design. Mostly because it's not even clear if a deleted/added file is even relevant with regards to class path resolution. Actually, I don't think we'd need moduleDeleted because that should be the same as invalidate, right? |
Hm, right, I guess the compiler would notice that the file doesn't exist anymore when invalidating a deleted file... |
I think the most straightforward way to implement moduleAdded is to invalidate all types (not just modules) that live in a module with the same name. It's a bit brute-force but I struggle to see how we would handle type resolution in the general case otherwise. |
Guys, what's the issue status? I'm asking because suppose it's rather critical and basic aspect of editor language support. |
Would be nice to have for 4.0 indeed, as it's pretty annoying when working in VS Code. |
I'm willing to work on this, but I can't do much on the vshaxe side because it only compiles for @Gama11 these days. I'll try to construct a failing test case for this |
* [tests] generalize server tests a bit * [std] steal some types from vshaxe * [tests] start on server display tests see #8451 * remove CompilerMetadata type * bring back methods * add haxe.display.Server too * utilize methods for tests
I have added |
@Gama11's observation is correct: If the module is created in an empty state and only "filled out" later, the type is not picked up. The following test sequence doesn't pass:
Note that this problem is not specific to the new moduleCreated feature. I think we have mark files upon invalidation and then re-parse them on the next request that utilizes the syntax cache (unless they were already handled inbetween). |
I have committed this approach. There's still an open debate I'm having with myself about whether or not the The only way to handle that would be to check the modification time of all files in the syntax cache, which would likely be insanely slow. |
I think we're done here. |
The completion server has a syntax cache for things like toplevel completion. It is initialized once on startup with
server/readClassPaths
. The problem is that after this point, it is never updated again.Here's an example with a newly created
Test
type, which doesn't show up in completion and thus can't be auto-imported. It only shows up after restarting the language server.Conversely,
Test
will still show up after it has been deleted:To avoid these issues, Haxe needs to update its syntax cache dynamically when types are added or removed. We probably also need some new methods (
server/moduleCreated
/server/moduleDeleted
?) to inform Haxe about changes based on file watcher events (similar to theserver/invalidate
we already have).The text was updated successfully, but these errors were encountered: