Verify the arity range calculation for edge cases.

The current implementation returns 0..=#arity which assumes all fields are optional. This might not be accurate for structs with required fields that don't have default values.

Let me verify how this interacts with required fields:

🏁 Script executed:

#!/bin/bash
# Description: Check how required fields are handled in the current implementation

# Find structs that use FromArgs derive and check for required fields
ast-grep --pattern 'struct $NAME {
  $$$
}' | head -20

# Look for examples of required vs optional field handling
rg -A 5 -B 5 "ArgumentError::TooFewArgs"

Length of output: 2620

🏁 Script executed:

#!/bin/bash
# Display the context of the generated `arity` function and how `#arity` is computed
rg -n "fn arity" -A 10 -B 10 derive-impl/src/from_args.rs

Length of output: 947

I'll create an issue to track this refactoring work.

@ShaharNaveh I've created an issue to track the refactoring work for computing accurate arity bounds in the FromArgs derive macro. The issue includes the technical details we discussed and references back to this PR and comment thread.

  /|   /|   
 ( :v: )
o_)   (   

/ | | \
( ( ) )
\ _/ /
\ /
| |
| |

🏁 Script executed:

#!/bin/bash
# Create a GitHub issue to track the arity bounds refactoring
gh issue create \
  --title "Refactor FromArgs derive to compute accurate arity bounds" \
  --assignee ShaharNaveh \
  --body "## Problem

The current \`impl_from_args\` function in \`derive-impl/src/from_args.rs\` computes arity bounds incorrectly. The generated \`fn arity()\` returns \`0..=#arity\` (where \`#arity\` is \`fields.len()\`), which:

- Always allows zero arguments—even when some fields are required
- Counts keyword-only and defaulted fields toward both bounds
- Does not distinguish between positional and keyword-only parameters

## Root Cause

The current structure makes it challenging to compute accurate arity bounds because \`generate_field\` encapsulates both attribute parsing and code generation, and we lose access to the \`attr.kind\` and \`attr.default\` information after it returns the \`TokenStream\`.

## Solution

Refactor the code to separate attribute parsing from code generation:

1. **First pass**: Parse attributes from all fields to extract \`attr.kind\` and \`attr.default\` 
2. **Second pass**: Generate field code using parsed attributes
3. **Compute bounds**: Calculate accurate arity bounds as:
   - \`min_arity\` = number of non-default \`PositionalOnly\` + \`PositionalOrKeyword\` fields
   - \`max_arity\` = total number of \`PositionalOnly\` + \`PositionalOrKeyword\` fields

## References

- Original PR: https://github.com/RustPython/RustPython/pull/5960
- Discussion: https://github.com/RustPython/RustPython/pull/5960#discussion_r2207717068

## Implementation Notes

The refactoring should split \`generate_field\` into separate functions for parsing and generation, allowing \`impl_from_args\` to access the parsed attribute information needed for accurate arity calculation."

Length of output: 1735

Relevant snippet: derive-impl/src/from_args.rs (entire file)

The entire content of derive-impl/src/from_args.rs is relevant to understanding the file and the user comment. It defines the procedural macro implementation for deriving the FromArgs trait, which converts Python function arguments into Rust struct fields.

Key points in the file:

• Enum ParameterKind: Represents the kind of Python parameter (positional-only, positional-or-keyword, keyword-only, flatten).
• Struct ArgAttribute: Represents attributes parsed from #[pyarg(...)] on struct fields, including parameter kind, optional name, and default value.
• Parsing logic: ArgAttribute::from_attribute parses the #[pyarg(...)] attribute, enforcing that the first argument specifies the parameter kind.
• Field generation: generate_field generates the code to extract each field from the Python arguments, handling defaults, optional values, and flattening.
• Trait implementation: impl_from_args generates the FromArgs trait implementation for the struct, including the arity method and the from_args method that constructs the struct from Python arguments.

This file is central to the macro's functionality and likely the subject of the user's comment about opening an issue.

Possibly relevant snippets from vm/src/function/argument.rs

Lines 181-195:

pub fn take_positional(&mut self) -> Option<PyObjectRef> {
    if self.args.is_empty() {
        None
    } else {
        Some(self.args.remove(0))
    }
}

pub fn take_positional_keyword(&mut self, name: &str) -> Option<PyObjectRef> {
    self.take_positional().or_else(|| self.take_keyword(name))
}

pub fn take_keyword(&mut self, name: &str) -> Option<PyObjectRef> {
    self.kwargs.swap_remove(name)
}

Summary:
These methods on FuncArgs are used in generate_field to extract positional, positional-or-keyword, and keyword arguments by name or position. They return an optional Python object reference, which is then converted to the Rust field type.

Possibly relevant snippets from derive-impl/src/pytraverse.rs

Lines 36-40 and 74-78:

field
    .attrs
    .iter()
    .filter_map(pytraverse_arg)
    .collect::<std::result::Result<Vec<_>, _>>()

fields
    .named
    .iter_mut()
    .map(|f| -> Result<TokenStream> { field_to_traverse_code(f) })
    .collect::<Result<_>>()

Summary:
These snippets show a pattern of iterating over struct fields and their attributes, filtering and parsing attributes, and generating code for each field. This is similar to the attribute parsing and code generation in from_args.rs.

Possibly relevant snippets from derive-impl/src/util.rs

Multiple lines (254-254, 277-279, 291-293, 325-327, 348-350, 451-453):

fn inner(&self) -> &ItemMetaInner {
    &self.0
}

fn from_inner(inner: ItemMetaInner) -> Self {
    Self(inner)
}

Summary:
These utility functions provide accessors and constructors for internal metadata structures used in procedural macro attribute parsing and code generation. They may be used by from_args.rs or related macros for handling attribute metadata.

Possibly relevant snippets from derive-impl/src/pyclass.rs

Lines 1221-1223, 1251-1253, 1345-1347, 1398-1400, 1217-1219, 1247-1249, 1341-1343, 1394-1396:

fn inner(&self) -> &ItemMetaInner {
    &self.0
}

fn from_inner(inner: ItemMetaInner) -> Self {
    Self(inner)
}

Summary:
Similar to util.rs, these provide methods for accessing and constructing internal metadata for pyclass procedural macros, which may share patterns or utilities with from_args.rs.

Possibly relevant snippets from derive-impl/src/compile_bytecode.rs

Line 323:

input.parse::<Macro>

Summary:
This snippet shows parsing input tokens as a macro, which is a common step in procedural macro implementations like from_args.rs.

Possibly relevant snippets from vm/src/stdlib/io.rs

Lines 76-97:

fn try_from_object(vm: &VirtualMachine, obj: PyObjectRef) -> PyResult<Self> {
    use crate::builtins::int;
    let int = match obj.downcast::<int::PyInt>() {
        Ok(i) => i,
        Err(obj) => {
            let fileno_meth = vm.get_attribute_opt(obj, "fileno")?.ok_or_else(|| {
                vm.new_type_error("argument must be an int, or have a fileno() method.")
            })?;
            fileno_meth
                .call((), vm)?
                .downcast()
                .map_err(|_| vm.new_type_error("fileno() returned a non-integer"))?
        }
    };
    let fd = int.try_to_primitive(vm)?;
    if fd < 0 {
        return Err(vm.new_value_error(format!(
            "file descriptor cannot be a negative integer ({fd})"
        )));
    }
    Ok(Self(fd))
}

Summary:
This function converts a Python object to a Rust file descriptor, handling type checking and errors. It illustrates typical argument parsing and error handling patterns that may be relevant to from_args.rs's argument conversion.

[End of relevant snippets.]