[ruff] Detect mutable defaults in dataclass field
calls (RUF008
)
#16883
+246
−55
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Extend
RUF008
to catch mutable default values supplied viadataclasses.field
andattrs.field
calls. Previously,RUF008
only flagged direct assignments likemutable_default: list[int] = []
, and ignored cases such asattrs.field(default=[])
withinattrs
-decorated classes. The rule now inspects calls to field helpers and emits a diagnostic if thedefault
keyword is a mutable literal.Test fixtures for both dataclasses and attrs classes were updated to include explicit
field(default=[])
cases, the attrs fixture now importsattrs
so that these calls are resolvable, and snapshots were updated accordingly.Test Plan
Built the workspace (
cargo check
) and ran Ruff against the updated fixtures:reports both direct mutable defaults and
attrs.field(default=[])
defaults. A minimal reproduction of the original issue:now yields two
RUF008
diagnostics as expected.Running the hooks (
cargo fmt
,cargo clippy
, etc.) and pre-commit checks pass after formatting, and updated snapshot tests reflect the new diagnostics.This PR was generated by an AI system in collaboration with maintainers: @carljm, @ntBre
Fixes #16495