Add #[allow(...)] directives to macro-generated entries

[mivort]

This patch adds #[allow(non_camel_case_types)] and #[allow(non_upper_case_globals)] directives to generated consts and structs.

While cargo check by default ignores naming style inconsistencies in macro-produced code, rust-analyzer seems to be using a more strict mode. #[allow(...)] annotations for generated entries allows to prevent the display of such warnings by the language server.

Context

Without this patch, rust-analyzer produces the following type of stylistic warnings (tested in Neovim v0.10.4 / rust-analyzer v1.84.1):

When using #[derive(GodotConvert)] macro:

1. Constant `ORD_SharedInventory` should have UPPER_SNAKE_CASE name,
   e.g. `ORD_SHARED_INVENTORY` [non_upper_case_globals]

When using #[derive(GodotClass)] macro:

1. Structure `__gdext_CameraControl_Funcs` should have UpperCamelCase name,
   e.g. `GdextCameraControlFuncs` [non_camel_case_types]

[GodotRust]

API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-1049

[Bromeon]

Thank you! 🙂

Do you think there's an easy way how we could detect such cases in CI, without adding rust-analyzer as a dependency? With cargo check (or clippy), this cannot be detected?

[mivort]

@Bromeon I've tried to check the docs for possible options to enable warnings produced during proc macro compilation (inline macros show these warnings), haven't found any. Some linters are disabled explicitly for macros in compiler code, but that's not the case for naming checks (so that's probably why rust-analyzer is able to produce these).

There should be some logic in Rust compiler which discards/doesn't output warnings (errors are still kept, obviously), I wonder if it's externally configurable, though.

[Bromeon]

Thank you! I think this is good for now, in case you come across easy ways to prevent this in the first place, let us know 👍