-
Notifications
You must be signed in to change notification settings - Fork 58
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
Does this support auto-import? #2
Comments
Not yet, and yes the compiler can probably help. It might even be possible to let it do all the work because the compilation server already caches all types anyway (well, all types that have been compiled so far, but that's an issue for usage-display as well). |
Several people have asked me about this and I see that would be a great feature indeed, but I think we can't just look at the compiler cache to find those, since some of the types from classpaths or libraries that we'd like to auto-import could be unused yet. It appears to me that this feature might work similar to |
…milar to TS version, also don't mess with Void and use special NoData type (see #2)
This works now. There's still a problem in some cases because some candidate types might simply not be known to the compiler, but that's a more general problem which we're keeping track of in https://github.com/vshaxe/haxe-languageserver/issues/5 among other places. Let me know if you come across any issues with this. |
@Gama11 says I don't know what auto-import is and that it doesn't work yet. |
Last time I checked this, I think I found out that the compiler (right now) doesn't even have a list of imported types in a given module it could include in display responses (which we need to be able to tell whether or not to generate an import or not). So, marking as blocked. |
In IDEA, we used haxelib to give us a list of libraries, and then we parsed/indexed the libraries to get that list. We still have bugs in that code, but it mostly works. (In fact, I think Boyan even added some code to look in the repository and have haxelib download them for use.) |
Do you handle |
@EricBishton, it still doesn't work with my IDEA at least. I have to manually add libraries I use to the IDEA project to have them included when it looks for symbols to import. |
@Gama11 I'm not sure what you mean. (And we can take that discussion out of this bug, if it's a rabbit trail.) BTW, I was NOT trying to toot the IDEA horn in the vshaxe repo. I was trying to be helpful and point to a solution that you may be able to use/hijack. @b005t3r Most people find it too aggressive, rather than find it not working. |
@EricBishton, I guess that's what makes me special :) You can test one of my projects and see if it works for you (it doesn't work for me with this project): https://github.com/b005t3r/TexturedCube3D-hx |
Together with the latest Haxe 4 dev branch, the next vshaxe release will finally support auto-import: Note: this currently still has the limitation of only showing types that the compiler actually sees during compilation (has to already be imported / used somewhere). See HaxeFoundation/haxe#7004. |
With @Simn's latest Haxe improvements, the limitation of it only finding types that are included in compilation is not present anymore either. That means we should now have a fully-functional auto import. :) |
(Except for the inaccurate shadowing checks) |
As described here snowkit/atom-haxe#36?
Basically this requires a cache of all types from all class paths, even sub-types inside a module. So I think this requires compiler support.
The text was updated successfully, but these errors were encountered: