Exposing the Godot GDScript parser/analyzer/compiler in a standalone project

[cryeprecision]

Hi,

I recently stumbled upon the same issue with writing a formatter/linter for GDScript that you describe in #356, i.e., we don't have any semantic information about the source code.

I thought about creating another project that includes Godot as a submodule and exposes just the GDScript parser/analyzer/compiler to build upon. Maybe even as a simple C API which would allow using the parser/analyzer/compiler from any language that supports C FFI, but I think this would mean a lot of work.

Expsing the parser/analyzer/compiler would also enable the creation of standalone tools similar to Golangs gofmt and go vet.

What do you think about this?

[HeavyBro1337]

I think that is a more reasonable approach compared to having own solution. That ensures compatibility and less maintainability. E.g. adding new typed dictionaries.

[Scony]

IMO we should eventually implement such tools within the Godot itself. That would be ideal. Also - if we'd have proper regression tests then - in case someone adds new syntax to Godot, the same person would have to implement/align the formatter/linter/re-orderer side within the same PR as otherwise the tests would be failing.

With that the solution would be simple and stable while the maintenance cost would be distributed among Godot contributors.