Prevent procedural macro hygiene issue with eager macros

[mivort]

This PR adds a change which links together identifiers in quote! expansion. While in normal context, there's no issues with expansion of procedural macro #[func] attribute, Rust macro hygiene rules start to apply within the context of eager2 crate.

Context/use case

I'm using eager2 crate to implement makeshift mixin pattern for exported GDExtension classes. This allows to define 'interface' as macro once, and then apply the same #[func]/#[signal]/#[property] 'signature' to multiple exported classes, embedding it as tokens (so #[godot_api] is able to catch the #[func] attribute).

#[eager_macro]
macro_rules! common_method {
    () => {
        #[func]
        fn common_method(&self) { self.common_trait_method() }
    };
}

eager! {
    #[godot_api]
    impl Foo {
        common_method!()
    }
    #[godot_api]
    impl Bar {
        common_method!()
    }
}

Even beyond this use case, eager2 macro is overall infinitely useful and powerful, as it allows to define and perform eager macro expansion (similar to built-in ones, such as concat) - there's a chance that similar functionality will make it into 'declarative macros 2.0' proposal in Rust language some time later.

However, recent changes to the #[func] attribute expansion started causing this type of error:

error[E0425]: cannot find value `params` in this scope
  --> [...]:34:1
   |
34 | / eager! {
35 | |     #[godot_api]
36 | |     impl Foo {
37 | |         common_method!()
...  |
40 | | }
   | |_^ not found in this scope
   |
   = note: this error originates in the macro `interface_equipment` which comes from the expansion of the macr
o `eager` (in Nightly builds, run with -Z macro-backtrace for more info)

So during the expansion of #[godot_api] within eager context, hygiene rule for params trigger, preventing the compiler from matching the identifier referenced with #param_ident to params. Use of consistent identifier reference (#param_ident in both argument list and function body, with same span) prevents this issue and allows to keep using the eager expansion.

[GodotRust]

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

[Bromeon]

Thanks a lot, great discovery and super nice that it's so simple to fix. Span improvements are always appreciated; we started with #1370 and #1373, but there is a lot left to do 🙂

Could you add a comment about macro hygiene (and maybe a link to this PR) above the changed lines, so that we don't risk accidentally re-introducing it again? Please squash commits with existing one.

Do you think there's a way to test this without depending on eager or another third-party crate?

[mivort]

@Bromeon Added a comment about the requirement to provide spans to the identifiers with a link to this PR for context, is the explanation for it correct?

I haven't reproduce the issue outside of eager crate usage, but I believe a small subset of its functionality (a minimal #[proc_macro]) may be able to trigger the hygiene issue. I'll try with other macros and this change reverted to see if there's a simpler way to get this error.

[Bromeon]

Thanks!

[Bromeon]

godot-itest (macos-x86-4.4)
This is a scheduled macos-13 brownout. The macOS-13 based runner images are being deprecated. For more details, see actions/runner-images#13046.

OK, that's probably the end of the line for our macOS Intel support 🥲