Hi, thanks for the swift fix! I had some time to dig a little deeper.

The minimal fix, moving iter.next() so the iterator always advances, prevents
the proc-macro hang. That is good, but by itself it can turn qualified helper
attributes such as #[vm::pymethod] into a silent no-op: the compiler no longer
hangs, but the method is not registered either.

I think the open design choice is whether RustPython helper attributes inside
the macro body should support qualified paths.

Option A: support qualified helper attributes

Treat both #[pymethod] and #[vm::pymethod] as pymethod, by recognizing the
final path segment.

Sketch:

fn helper_attr_ident(attr: &Attribute) -> Option<&Ident> {
    attr.path().segments.last().map(|segment| &segment.ident)
}

Then use that helper instead of get_ident() in the pyclass.rs and
pymodule.rs attribute scans:

if let Some(ident) = helper_attr_ident(attr) {
    let attr_name = ident.to_string();
    if attr_name == "cfg" {
        cfgs.push(attr.clone());
    } else if ALL_ALLOWED_NAMES.contains(&attr_name.as_str()) {
        break;
    }
}
iter.next();

The AttributeExt helpers in util.rs also need the same path handling, since
recognized qualified helper attributes will later flow through
ident_and_promoted_nested().

Good:

• Matches user expectations when rustpython_vm is imported as vm.
• Avoids both the hang and the silent skip.
• Makes inner helper attributes feel consistent with outer macros like
  #[vm::pyclass].
• Supports arbitrary crate aliases, not just vm.

Bad:

• A proc macro cannot prove that vm resolves to rustpython_vm; it only sees
  tokens.
• Any attribute path ending in a RustPython helper name, for example
  #[other::pymethod], would be treated as that helper inside RustPython macro
  contexts.

Option B: reject qualified helper attributes clearly

Accept #[pymethod], but emit a diagnostic for #[vm::pymethod].

Sketch:

fn helper_attr_ident(attr: &Attribute) -> Option<&Ident> {
    attr.path().segments.last().map(|segment| &segment.ident)
}

fn helper_attr_is_unqualified(attr: &Attribute) -> bool {
    attr.path().segments.len() == 1
}

Phase 1 still needs to look at the final segment so it stops before a qualified
helper attribute and lets phase 2 report the error:

if let Some(ident) = helper_attr_ident(attr) {
    let attr_name = ident.to_string();
    if helper_attr_is_unqualified(attr) && attr_name == "cfg" {
        cfgs.push(attr.clone());
    } else if ALL_ALLOWED_NAMES.contains(&attr_name.as_str()) {
        break;
    }
}
iter.next();

Then phase 2 can reject the qualified helper attribute explicitly:

let Some(ident) = helper_attr_ident(attr) else {
    continue;
};
let attr_name = ident.to_string();

if !helper_attr_is_unqualified(attr) && ALL_ALLOWED_NAMES.contains(&attr_name.as_str()) {
    bail_span!(
        attr,
        "qualified RustPython helper attributes are not supported here; use #[{}] instead",
        attr_name
    );
}

Good:

• More conservative.
• Avoids consuming unrelated attribute paths that merely end in pymethod.
• Keeps the supported syntax narrower and easier to reason about.

Bad:

• Less ergonomic, especially because users can already write qualified outer
  macros like #[vm::pyclass].
• Requires users to mix qualified and unqualified RustPython attributes.
• Still needs explicit detection to avoid silent skips.

@mapf0000 you are right that current behavior is wrong. Thank you for feedback.

@copilot you must add a test that the new code is working correctly. also check mapf0000's suggestion about vm::pymethod. Can Rust proc-macro recognize vm as a symbol of imported namespace? e.g. use rustpython_vm must allow rustpython_vm::pyemthod and use rustpython_vm as vm must allow vm::pymethod. It doesn't likely to be. If that's impossible, when {}::pymethod exists, we must warn user to use #[pymethod] rather than the wrong namespace notation.

@mapf0000 you are right that current behavior is wrong. Thank you for feedback.

@copilot you must add a test that the new code is working correctly. also check mapf0000's suggestion about vm::pyme...

Done — addressed both points (commits cover the latest two changes on top of the original fix):

Namespace alias question: proc-macros receive raw token trees before name resolution, so vm in #[vm::pymethod] is just an opaque identifier — the macro has no way to know it's an alias for rustpython_vm. The qualified form cannot be supported.

Warning for #[vm::pymethod]: Both loops in attrs_to_content_items now detect when a multi-segment attribute path ends with a known py* name. The while loop breaks (so the attribute isn't silently consumed) and the for loop emits a compile error that names the full path written and the correct unqualified form, e.g.:

error: found `#[vm::pymethod]`, use `#[pymethod]` instead; proc-macros cannot resolve namespace aliases

Test: Added a runtime test in crates/vm/src/lib.rs that defines a TestItem struct with #[pyclass]/#[pymethod], instantiates it, and asserts item.value() == 42, verifying the macro-generated code is functionally correct. For compile-fail coverage of the new error (the #[vm::pymethod] → error path), that would need trybuild infrastructure which isn't currently set up in the repo.

@copilot we all know #[pymehtod] works well because the entire codebase is using it. you must test using #[something::pymethod] actually fails

@copilot we all know #[pymehtod] works well because the entire codebase is using it. you must test using #[something::pymethod] actually fails

Added a unit test directly in crates/derive-impl/src/pyclass.rs that calls attrs_to_content_items with a syn::parse_quote!(#[vm::pymethod]) attribute and asserts:

1. The result is an Err (not an infinite loop or silent success)
2. The error message contains both the full path (vm::pymethod) and the unqualified name (pymethod)

Commit: the latest commit test: add unit test in derive-impl verifying path-qualified py attrs return an error.