New declarative macros, functions and fields not being recognized

[BeastLe9enD]

I ran into some issues with rustc 1.58.0-nightly (b426445 2021-11-24).
I have the following code:

#![feature(decl_macro)]

pub macro generate_class_new($name: ident) {
    pub struct $name {
        x: i32
    }

    impl $name {
        pub fn new(x: i32) -> Self {
            Self { x }
        }
    }
}

generate_class_new!(MyTestClass);

fn main() {
    let instance = MyTestClass::new(3);
}

What I try to do here is creating a macro that just creates a struct with a given identifier as a name.
When I call MyTestClass::new(3), the compiler complains that this function does not exist:

error[E0599]: no function or associated item named `new` found for struct `MyTestClass` in the current scope
  --> src/main.rs:18:33
   |
4  |     pub struct $name {
   |     ---------------- function or associated item `new` not found for this
...
18 |     let instance = MyTestClass::new(3);
   |                                 ^^^ function or associated item not found in `MyTestClass`

running cargo expand produces code that should work in my opinion:

#![feature(prelude_import)]
#![feature(decl_macro)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
pub macro generate_class_new($ name : ident) {
    pub struct $name {
        x: i32,
    }
    impl $name {
        pub fn new(x: i32) -> Self {
            Self { x }
        }
    }
}
pub struct MyTestClass {
    x: i32,
}
impl MyTestClass {
    pub fn new(x: i32) -> Self {
        Self { x }
    }
}
fn main() {
    let instance = MyTestClass::new(3);
}

Not sure if I'm doing something wrong here, but it pretty much looks like a bug for me

[camelid]

My recollection is that declarative macros use "def-site" hygiene; that is, identifiers defined in the macro are scoped to the macro and cannot be referenced outside the macro.

Passing new as an argument to the macro makes the program compile successfully:

#![feature(decl_macro)]

pub macro generate_class_new($name: ident, $new: ident) {
    pub struct $name {
        x: i32
    }

    impl $name {
        pub fn $new(x: i32) -> Self {
            Self { x }
        }
    }
}

generate_class_new!(MyTestClass, new);

fn main() {
    let instance = MyTestClass::new(3);
}

[MSxDOS]

It works fine with old declarative macros: https://rust.godbolt.org/z/35oYrPv7E and that's how they're often used, including std.
So either it's a bug with declarative macros 2.0 or they're fundamentally useless.

[BeastLe9enD]

Yes, with macro rules, its working as intended. But with the new gen 2.0 macros it doesn't.

[camelid]

IIRC, part of the reason for adding macros 2.0 was to have def-site hygiene. But I'm not sure, so I'll ask on Zulip.

[BeastLe9enD]

Yea, wasn't really sure if its actually a bug or my mistake, but in my opinion it would be great if it would work because I think many people including me use macros for things like that, sure u could use macro_rules in that specific case, but perhaps one could initiate a little discussion in this context

[camelid]

I started a thread on Zulip about this.

[camelid]

@bjorn3 replied on Zulip and also thinks this is intended behavior. I'm going to nominate this for T-lang since the behavior seems to be surprising to users.

[BeastLe9enD]

I don't know if there is a better way to implement this, but you could put a $ in front of the identifier, if the identifier is not in the pattern, the identifier has the same * value * as its name and has a global scope

[camelid]

I don't know if there is a better way to implement this, but you could put a $ in front of the identifier, if the identifier is not in the pattern, the identifier has the same * value * as its name and has a global scope

I'm pretty sure $foo with no corresponding argument pattern is already accepted to mean $ foo.

[PatchMixolydic]

Perhaps metavariable expression syntax could be used? This would give us something like pub fn ${escaping_ident(new)} (though the final product would probably have a better name).

I do feel that while the limitations are a bit surprising coming from macros 1.0, they ultimately make hygiene more consistent.