Skip to content
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

Autocompletion doesn't work for generated files #40

Closed
rlidwka opened this issue Dec 2, 2022 · 2 comments · Fixed by #48
Closed

Autocompletion doesn't work for generated files #40

rlidwka opened this issue Dec 2, 2022 · 2 comments · Fixed by #48
Labels
bug c: tooling CI, automation, tools

Comments

@rlidwka
Copy link

rlidwka commented Dec 2, 2022

In the absence of documentation, the best way to figure things out is IDE autocompletion. Sadly, for generated files it doesn't work (at least in vscode on windows).

I've opened the issue here, please check it out:

rust-lang/rust-analyzer#13711

Long story short, generated files are located in a different package from where they are included (godot-codegen vs godot-core). And that makes them invisible as far as autocompletion is concerned.

Not sure if it's intentional or not on the part of rust-analyzer, so opening an issue on both places.

@rlidwka
Copy link
Author

rlidwka commented Dec 2, 2022

In case you don't have VSCode, this is what I have by default:

image

And this is what happens if I move /target/godot-gen anywhere inside of godot-core module:

image

@Bromeon Bromeon added bug c: tooling CI, automation, tools labels Dec 2, 2022
@Bromeon
Copy link
Member

Bromeon commented Dec 3, 2022

This problem is also present on CLion, and I agree we should do something about it. Good that we have this issue now 🙂

The location where code is generated is indeed rather hacky at the moment. The problem is that not one, but two crates need code generation:

  • godot-ffi for low level "sys" symbols
  • godot-core for classes, utility functions, enums etc.

I could let both directly depend on godot-codegen, however that would mean that some effort is duplicated (notably parsing the JSON file and caching some symbols). This may not be such a big issue however.

An alternative would be to split generated classes into their own crate (like it's done with gdnative), which might also help compile times. godot-core could then depend on that crate. The problem here is that there are quite a few bidirectional dependencies (e.g. classes use Gd, but Gd also needs to know about Object and RefCounted classes). It's likely possible to detangle this through certain abstractions, but it might be a bit of effort. I'm also a bit scared of silly orphan-rule limitations if trait implementations need to be split across crates.

Maybe in the short term I could undo the change I made to generate everything inside the target folder -- the disadvantage would then again be that build artifacts are scattered in the file structure, and one cannot simply clean everything by e.g. deleting the target directory. Maybe godot-codegen should do that as a first step in its invocation, so that at least no old symbols remain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug c: tooling CI, automation, tools
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants