fix(plugins): reject #[default] on a struct member - #10228
Conversation
|
This change is |
PR SummaryLow Risk Overview A derive plugin test adds Reviewed by Cursor Bugbot for commit 3682588. Bugbot is set up for automated code reviews on this repo. Configure here. |
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on orizi and TomerStarkware).
crates/cairo-lang-plugins/src/test_data/derive line 867 at r1 (raw file):
error: `#[default]` is only supported for enum variants.
#[default] is not supported on struct members
`derive(Default)`'s enum arm diagnoses `#[default]` (requiring exactly one default variant), but the struct arm never inspected member attributes. Since `#[default]` is registered globally, placing it on a struct field neither tripped the unknown-attribute check nor did anything — it parsed, emitted no diagnostic, and was silently discarded, producing byte-identical Sierra with or without the attribute. This contradicts the corelib docs, which scope `#[default]` to enum variants. Have the struct arm iterate the members and emit an error for any field carrying `#[default]`. The best-effort `Default` impl is still generated (no early return), matching the derive's existing error-recovery behavior. Adds a regression case to the derive diagnostics golden.
28f63c1 to
3682588
Compare
orizi
left a comment
There was a problem hiding this comment.
@orizi made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on eytan-starkware and TomerStarkware).
crates/cairo-lang-plugins/src/test_data/derive line 867 at r1 (raw file):
Previously, eytan-starkware wrote…
#[default] is not supported on struct members
Done.
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on TomerStarkware).
Summary
Adds a diagnostic error when
#[default]is used on a struct member duringDefaultderivation. Previously, applying#[default]to a struct field was silently ignored — the derive macro would still generate a validDefaultimplementation without any indication that the attribute had no effect. Now, a clear error is emitted pointing to the offending attribute.Type of change
Please check one:
Why is this change needed?
#[default]is only meaningful on enum variants when derivingDefault. When a user mistakenly places it on a struct member, the attribute was previously silently ignored, giving no feedback that the annotation was invalid or had no effect. This could lead to confusion about what the attribute does.What was the behavior or documentation before?
Using
#[default]on a struct member with#[derive(Default)]produced no diagnostic. TheDefaultimplementation was generated as if the attribute were not present.What is the behavior or documentation after?
Using
#[default]on a struct member with#[derive(Default)]now produces a compile error:The error points directly to the offending
#[default]attribute on the struct member.Related issue or discussion (if any)
N/A
Additional context
N/A