bugfix(semantic): writeln!(f) with no format string writes a newline. - #10182
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryLow Risk Overview
Snapshot diagnostics for bad Reviewed by Cursor Bugbot for commit 030ea75. Bugbot is set up for automated code reviews on this repo. Configure here. |
`writeln!(f)` (a formatter with no format string) errored with "Macro expected format string argument", though in Rust it writes just a newline. Accept the no-format-string case for `writeln!` and emit a newline; `write!(f)` still requires a format string. This also makes `println!()` valid — it expands to `writeln!(f, )` — matching its documented "prints an empty line" example, while `print!()` → `write!(f, )` still errors.
58e8554 to
030ea75
Compare
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).

Summary
writeln!(f)with no format string argument now writes a newline character instead of emitting a compile error.println!()with no arguments also compiles via the same expansion path.write!(f)andprint!()without a format string still produce an error.Type of change
Please check one:
Why is this change needed?
writeln!(f)is valid Rust — it writes a bare newline to the formatter without requiring a format string. Cairo's implementation unconditionally required a format string argument for bothwrite!/writeln!, causingwriteln!(f)to fail with"Macro expected format string argument."instead of emitting"\n".What was the behavior or documentation before?
writeln!(f)andprintln!()both produced a compile-time plugin diagnostic:"Macro expected format string argument.".What is the behavior or documentation after?
FormattingInfo::extractnow receives thewith_newlineflag. When no format string is provided andwith_newlineistrue, it returns aFormattingInfowith an empty format string instead of an error, causing the macro to emit just a newline. Whenwith_newlineisfalse(write!/print!), the original error is still returned.A regression test (
writeln_no_format_string) verifies thatwriteln!(f)appends"\n"to the formatter buffer and thatprintln!()compiles successfully.Related issue or discussion (if any)
Additional context
The
format_string_argfield in the no-format-string path reuses the formatter argument node as a placeholder since no actual format string node exists. This is safe because the field is unused when the format string is empty.