zigtools
goto definition: very basic support for extern fn gotodefinition
This might be way out of scope for the project - I could see this both potentially being fairly straightforward (a basic implementation), or an absolute pain.
Good zig interopability with C (and to a limited extent C++), is one of the killer features of the language (especially with the cross-compilation facilities of the compiler and it being a "better clang" than clang). Especially important in allowing zig to potentially be used in large pre-existing codebases - important in some domains such as the games industry where few (if any) studios are writing game engines from scratch. (Even if they were - the dependencies on third party C++ libraries like Havok to make that even viable still requires a lot of support for C++ interopability).
Therefore it would be great if you could click on an extern fn declared in zig - and goto a best-guess appropriate C definition. I think the challenge here would be having to tokenise a bunch C/C++ files. I think even just jumping to any symbol match woud be fine - as once you are in C/C++ land the language server for those langauges can take over. Any decleration/definitions that come from macros are fine to be ignored as well IMO. A very basic solution would a good majority of cases - and make interopability that much nicer.
Not sure if there's maybe a "language server protocol way" of better inter-language operability (find all references working, refactors etc.). But this issue is not about that, it would be nice just to be able to navigate to functions for now (if that is possilbe with langauge server protocol in the first place!).
i bet we could open a feature request on https://github.com/ziglang/translate-c/ to add a config option that emits comments with the source location of the C decls. should make it fairly easy on the zls side
Having thought about it some more - one problem this solution doesn't solve is cases where translate-c hasn't been used and manual bindings have been written. (Which I do fairly often to make "safer" pointers.)
But with this comment format supported - it wouldn't be too tricky to write scripts to keep them updated in internal code bases (if not completely ideal), so as a solution it is workable for sure.
Thank you for following up on this as well!