Amazing for a baseline, but a bit broken.

[CantyCanadian]

I needed a set of bindings for your Lua API and this did an awesome job. I still wanted to node down a list of issues that can be manually fixed by the user, but might be worth investigating and fixing if it interests you:

• Certain subobjects uses the C++ writing style (Object::SubObject) instead of the C# style (Object.SubObject).
• Subtypes from Godot.Resource are missing the Resource object
  • Ex. ResourceDeepDuplicateMode cannot be inferred, must be Resource.ResourceDeepDuplicateMode.
• Conversion to and from Variant array types are broken in property definitions
  • Ex. int[] -> Array requires a call like "Variant.From(value).AsGodotArray()" which isn't inferred automatically, same with Array -> int[] needing something like ".ToArray()"
• Enum conversion is broken because C# cannot implicitely convert an enum to its index and vice versa.
  • Requires a cast, either (int)enumObject or (EnumType)index.
  • Some of those enums will also need their encompassing object, like TextEdit.CaretTypeEnum.
• Custom type conversion to and from Variant is extremely hit or miss.
  • For your API specifically, Array is invalid as it cannot be automatically converted to Variant and must thus be wrangled into submission via variant.Select(vari => (LuaDebug)vari).ToArray().
• uint aren't taken into account when generating functions, both as parameters or as return types. They become int, which aren't an implicit conversion to uint.
• double aren't taken into account either and are made into floats, which isn't a compatible implicit conversion.
• Properties that wraps other properties marked [Obsolete] should also be marked [Obsolete].
  • Ex. LuaCodeEdit.AutoTranslate.

As for very weird specific errors:

• Some functions tries to cast a value to int despite the function not needing any cast, and the cast causing an error. Seems to be the case with functions that requires passing an enum and the binding trying to cast it for no reason. Includes but not limited to:
  • LuaCodeEdit.AddCodeCompletionOptions
  • LuaCodeEdit.SetTextDirection
  • LuaCodeEdit.SetStructuredTextBidiOverride
  • LuaCodeEdit.StartAction
• Code is generated with typos.
  • LuaCodeEdit.GetFirstNonWhitespaceColumn -> WhiteSpace
  • LuaCodeEdit.GetWorld2d -> 2D
  • LuaCodeEdit.ImportPath -> _ImportPath
• For some reason, LuaCodeEdit.ShortcutContext gets converted to GodotObject instead of remaining a Node, leading to a casting error.

ALL THAT SAID, thank you for making this tool. Typing all this would've turned me off using Lua in my project so mad props.

[gilzoide]

Hey @CantyCanadian, thanks for the report.

Yeah, generating C# code for GDExtensions is not easy, Godot's own code generation is surprisingly difficult and full of edge cases 😅
Some of them, like the uint vs int one, I checked in Godot's code and it's defined in the native properties but that information isn't accessible in ClassDB, so hardcoding the properties was the only way I found to make it right.

After some testing, I'm thinking that maybe the best approach to this problem (generating C# wrappers for GDExtension classes) would be to do what CSharp-Wrapper-Generator-for-GDExtension does and instead of recreating the whole API in a wrapper C# class, it inherits the base class and defines the GDExtension wrappers as scripts. The caveat there is that GDExtension instances would need to not have scripts attached for this to work (so we can attach the C# wrapper script) and you can't really call new MyGDExtensionClass() because the base constructor for attaching a script to the instance is internal (a factory method works fine for this).
But it would remove all the complexity in trying to recreate the whole Godot API and focus only on the consts / enums / properties / signals / methods defined in the GDExtension class itself, which is much much easier to get right.