[RafaelJohn9]

Summary

Adds a new Ruff rule that flags method receiver parameters (self / cls) when they are given a default value.

The rule targets functions defined directly inside a class body and uses semantic context to ensure it only applies to methods, not standalone functions. It determines the receiver kind, inspects the first positional parameter, and reports a diagnostic when that receiver has a default value.

Closes #25820

Test Plan

Tested by adding a Ruff fixture and snapshot for RUF077, and verifying the rule is triggered for methods whose receiver parameter has a default value.

Files added/updated for testing include:

• crates/ruff_linter/resources/test/fixtures/ruff/RUF077.py
• crates/ruff_linter/src/rules/ruff/snapshots/ruff_linter__rules__ruff__tests__RUF077_RUF077.py.snap

I also validated the rule integration by building Ruff locally after registering the rule and hooking it into AST statement analysis.

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[ntBre]

Thanks! This looks good overall, but we need to make sure to add the rule in preview, and I think we can reuse some existing code for the static/class/instance method checks. I also had a request about the tests.

[ntBre]

Looking back at the issue, I also saw in Micha's comment:

We need to make sure to correctly handle @classmethod,__new__, ..., @override (any decorators?)

I think we may want to conservatively bail out in the presence of any other decorators, but especially @override, which indicates that the function was inherited and this definition doesn't control its signature.

[ntBre]

This relates to my inline comments, but the one ecosystem hit appears to be a false positive:

• airflow-core/src/airflow/api_fastapi/execution_api/versions/v2025_05_20.py:35:65: method-receiver-default Instance receiver parameter should not have a default value

The function has a decorator that we can't resolve and ends up producing a static method:

https://github.com/zmievsa/cadwyn/blob/22241f2d9d92e36d0222fd2536effb43b06e3b6e/cadwyn/structure/data.py#L209

[RafaelJohn9]

hello @ntBre , We good to go? :)

[ntBre]

Thank you! This is looking good, just a couple more edge cases to consider.

[ntBre]

I repeat this in the inline comment, but sorry for not noticing this earlier! I didn't realize we were doing all of this classification work just to customize the error message. I think we can just make the message suitably generic and then replace all of the receiver_kind stuff with something like:

let has_receiver = match decorator_list {
    [] => true,
    [decorator] => is_class_method(
        decorator,
        semantic,
        &checker.settings().pep8_naming.classmethod_decorators,
    ),
    _ => false,
};

if !has_receiver {
    return;
}

The custom messages were a nice touch, but it's not really clear what to do with a "maybe" metaclass, which drew my attention to this, and I think the overall simplification is a better tradeoff.

[ntBre]

Thank you! I pushed one small change documenting the options used, but this otherwise looks good to me!

Thanks for staying on top of all the merges and even picking a category! I think suspicious is perfect.