bindings not found by intellisense/autocomplete

[sprucely]

Please excuse my rust newbiness. Any suggestions on getting autocomplete working in rls-vscode for generated bindings? I can see the various generated [feature name]_types.rs in my project's folders under target/debug/build, and my code builds without complaint. But only non-generated types are shown in intellisense.

Since the godot-rust examples are tied to the project with relative path dependencies, I wasn't sure of the preferred method of referencing feature dependencies. My toml dependencies are declared as...

[dependencies]
gdnative = "0.6.0"
gdnative-editor = "0.6.0"
gdnative-audio = "0.6.0"
...

And I'm referencing them as separate crates in my code...

extern crate gdnative;
extern crate gdnative_editor;
extern crate gdnative_audio;
...

[nical]

I have no experience with intellisense, rls and the likes so I don't know how to help. Perhaps asking around in the #rust irc channel will get you some answers.

While I'm here, I want to point out that you don't have to import each gdnative_foo crate, you can instead just have a dependency on gdnative and enable feature flags. For example the "audio" feature will import all gdnative_audio types in the gdnative crate, etc. This way you can have a single dependency which is simpler when you want to update it.

example:

#[dependencies]
gdnative = { version = "0.6.0", features = ["graphics", "audio", "physics"] }

Back to your original question, I'm thinking of removing the code generation from the build and just check the generated files in. The disadvantage is that contributors need to know that they have to run the generator and not modify the generated files. I think that this can be solved by a bit of documentation and checking in CI that the generator produces exactly what is checked in. The advantages are:

• faster build times for users of the bindings (no need to build the generator and its dependencies),
• much much faster packaging time for me (for each gdnative_foo crate the cargo package and publish commands both build all dependencies including the generator, this adds up to more than 20 times and takes a long time),
• generated code would look like "normal" code and interact better with intellisense etc.

@karroffel what do you think?

[sprucely]

Ah, I had been confusing features with modules and wondering why I couldn't access anything under gdnative::editor.

Another question. Is there a gdnative equivalent of the "tool" keyword used in gdscript to allow editor integration? If not, that's fine, as I can just use gdscript for working with EditorPlugin. I'm hoping that registering my custom AudioStream will automagically get it included as an option in the AudioStreamPlayer's list of stream options.

Thanks!

[karroffel]

@nical I think we mentioned that before, vendoring could be a good option for most usecases.

I think there are some crates like openssl which have a feature that determines whether the system provided library should be used or the "vendored" one should be build by the crate.

Maybe we can do the same. Every gdnative_XXX crate could have a "vendored" feature that includes the bindings build by the packager. If that flag is disabled, then the bindings are generated in the call-site.

Seems like a good thing to me. If I want to do development stuff and use my IDE and get completion I could use the "vendored" feature, then when I want to build a release version or so I can switch to a trimmed down version that's build and doesn't provide completion.

[karroffel]

This problem has been there for years btw, it's still not fixed in racer as far as I know (racer-rust/racer#191), so I don't expect RLS or other completion engines to deal with it either :/

[karroffel]

Before the 0.7.0 release there was the idea floating around of releasing "vendored" code and not having to run the code generator all the time. This should also make autocomplete work better. (I have heard that IDEA-rust made advances in that area, supporting cases like ours, but I have not tested it)

#223 (comment)

[carmel4a]

So.. is there any way to enable code completion in IDE?
I can't reproduce this workaround: #270 (comment)
EDIT:
Ok, so if I understand this issue - the problem is that racer lib used by RLS can't parse macros as:
include!(concat!(env!("OUT_DIR"), "/foo.rs"));, yes?

[ATizik]

To make it work in CLion/Intellij Idea:

1. Help -> Edit Custom Properties
   Add the following line:
   idea.max.intellisense.filesize=999999
   Otherwise Idea skips bindings, as they are over the default limit of 2,56mb
2. Apply the following changes to godot-rust:
   Waridley@fcce3df

[Trayani]

UPDATE:
I got it working after re-building with deleted .cargo/registry, Cargo.lock and contents of /target folder :).

Hi, could we agree on more speciffic steps for the workaround? I did:

1. cloned godot-rust repo
2. applied the referenced adjustments above in gdnative-bindings
3. set the intellisense.filesize and also set "Expand declarative macros" setting to "Expand with experimantal engine" in IntelliJ.
4. made a simple "Hello world" project according to this tutorial and tested the .gnlib in godot (it works)
5. changed the dependency gdnative = "0.8" to gdnative = { path = "<path-to-adjusted-gdnative-bindings-folder>"} and rerun the build of the "Hello world" project.

It finished successfully, but the intellisense still does not react =(. Did I miss something?

[emigr2k1]

With rust-analyzer the following settings will make it work:

    "rust-analyzer.procMacro.enable": true,
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,

These settings will work in vim with coc.nvim and vscode. It should be similar for other lsp clients.

[ghost]

Great! I suppose this could be closed now?

[emigr2k1]

Yes. Rust-analyzer and IntelliJ support it now. RLS doesn’t but rust-analyzer is in the progress of replacing it.

[ghost]

I see. Closing then.

[karroffel]

With rust-analyzer the following settings will make it work:

Maybe something like that can be added to the README or the WIP book?

[emigr2k1]

I think it could be added to the introduction or the get-started section of the WIP book. A github wiki could also be added for relevant small bits of knowledege

[ghost]

I think README is a good place for now. We'll likely want to mention it in the book eventually as well, probably in the "getting started" guide.

[emigr2k1]

By the way, I came back to see the intellij config and noticed that it's suggested to apply a patch. That's not necessary.

You can go to help->Find Action->Experimental features... and activate the following features:

• org.rust.cargo.evaluate.build.scripts
• org.rust.cargo.fetch.out.dir

Now intellisense should work for the generated files.

[setzer22]

With rust-analyzer the following settings will make it work:

    "rust-analyzer.procMacro.enable": true,
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,

These settings will work in vim with coc.nvim and vscode. It should be similar for other lsp clients.

@emigr2k1 Total newbie here... Where should I place this config? Is this a rust-analyzer config, or is this VSCode specific?

EDIT: Ok, that was specific to VSCode. For anyone looking for emacs support, the equivalent config emacs is:

(setq lsp-rust-analyzer-proc-macro-enable 't)
(setq lsp-rust-analyzer-cargo-load-out-dirs-from-check 't)

[ricardoalcantara]

Sorry to revive this issue, but I am using gdnative = "0.9.3" and having this same problem, intellisense is not loading. I have enabled those properties proMacro and loadOutDirsFormCheck, I am also using the nightliy version of rust-analyiser with vscode and it's pretty hard to work without those features.

[Bromeon]

It seems like a few people have these issues at the moment, we're also discussing them in our Discord.
We had a similar, but not identical problem with CLion in #789.

I'm not using VSCode myself, but if someone has found a way to make the symbols work, would be appreciated to share them in #789 or the Discord!