Does this support auto-import?

[kevinresol]

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.

[Simn]

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).

[nadako]

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 module-symbols: parse the hx files and return types in them (and we could cache them on the IDE side, I guess). The obvious issue would be with macro-defined types though (like castledb's one for example), so I guess it's not that easy... Maybe we could have a fail-tolerant version of include().

[Simn]

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.

[Simn]

@Gama11 says I don't know what auto-import is and that it doesn't work yet.

[Gama11]

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.

[EricBishton]

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.)

[Gama11]

Do you handle import.hx yet? :)

[b005t3r]

@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.

[EricBishton]

@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.

[b005t3r]

@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

[Gama11]

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.

[Gama11]

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. :)

[Simn]

(Except for the inaccurate shadowing checks)