Formatter adds extra carriage return to multiline f-string debug replacements

[MeGaGiGaGon]

Summary

I noticed this while messing around on the playground, but it looks like formatting adds an extra \r to multiline f-string debug replacements. In combination with another software/editor that normalizes \r to \r\n, this causes the file to grow on every formatting.

The code I've been using to test this is

f"{
1=
}"

Where the line endings are \r\n

One example of this is on the playground. If you keep copying the output to the input, it keeps growing.
first step
second step
third step

Another example is inside VSCode, if you have line endings set to CRLF. After file modification and save inside VSC it normalizes the newlines, so by running ruff format -> do a edit like adding a 1 to the end of the file and save in VSC -> run ruff format -> repeat, the code grows every time.

I also made a powershell script to demonstrate this, where it replaces \r with \r\n to show the growth. (I tried to make a bash script, but I'm both not familiar enough with bash and it feels like every built in tool/command nukes/normalizes newlines).

PS script

Set-Content "issue.py" -Value "f`"{`r`n1=`r`n}`""
echo "issue.py content"
Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\n", "\n"} | ForEach-Object { $_ -replace "\r", "\r"}
echo "Running ruff format"
uvx ruff format issue.py
echo "issue.py content"
Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\n", "\n"} | ForEach-Object { $_ -replace "\r", "\r"}
echo "Newline normalization"
$edited = Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\r(?!\n)", "`r`n" }
Set-Content "issue.py" $edited
echo "issue.py content"
Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\n", "\n"} | ForEach-Object { $_ -replace "\r", "\r"}
echo "Running ruff format"
uvx ruff format issue.py
echo "issue.py content"
Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\n", "\n"} | ForEach-Object { $_ -replace "\r", "\r"}
echo "Newline normalization"
$edited = Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\r(?!\n)", "`r`n" }
Set-Content "issue.py" $edited
echo "issue.py content"
Get-Content issue.py -Raw | ForEach-Object { $_ -replace "\n", "\n"} | ForEach-Object { $_ -replace "\r", "\r"}

Output of script:

PS > ./issue.ps1
issue.py content
f"{\r\n1=\r\n}"\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\r\r\n1=\r\r\n}"\r\n
Newline normalization
issue.py content
f"{\r\n\r\n1=\r\n\r\n}"\r\n\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\r\r\n\r\r\n1=\r\r\n\r\r\n}"\r\n
Newline normalization
issue.py content
f"{\r\n\r\n\r\n\r\n1=\r\n\r\n\r\n\r\n}"\r\n\r\n

This only seems to happen when the f-string has a debug expression.

This also happens with t-strings

Version

ruff 0.11.13 (5faf72a 2025-06-05) + playground

[ntBre]

Interesting. I think I can reproduce this in the playground even without CRLF (though I'm not 100% sure which line ending is present). I can't seem to reproduce it in a Linux shell either, but I can definitely reproduce in VS Code by continuously hitting Ctrl+Shift+I to format:

[MeGaGiGaGon]

I think the playground normalizes both input and output to CRLF, so it wouldn't matter what you paste in. Editing my PS script it looks like it breaks with either CRLF or CR, but not just LF.

LF line endings start:

PS > ./issue.ps1
issue.py content
f"{\n1=\n}"\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\n1=\n}"\n
Newline normalization
issue.py content
f"{\n1=\n}"\n\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\n1=\n}"\n
Newline normalization
issue.py content
f"{\n1=\n}"\n\r\n

CR line endings start:

PS > ./issue.ps1
issue.py content
f"{\r1=\r}"\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\r1=\r}"\r
Newline normalization
issue.py content
f"{\r\n1=\r\n}"\r\n\r\n
Running ruff format
1 file reformatted
issue.py content
f"{\r\r\n1=\r\r\n}"\r\n
Newline normalization
issue.py content
f"{\r\n\r\n1=\r\n\r\n}"\r\n\r\n

[dylwil3]

I wonder if this is the relevant code? Debug text is formatted "verbatim":

ruff/crates/ruff_python_formatter/src/verbatim.rs

Lines 873 to 893 in 89d915a

	impl Format<PyFormatContext<'_>> for VerbatimText {
	fn fmt(&self, f: &mut PyFormatter) -> FormatResult<()> {
	f.write_element(FormatElement::Tag(Tag::StartVerbatim(
	tag::VerbatimKind::Verbatim {
	length: self.verbatim_range.len(),
	},
	)));
	match normalize_newlines(&f.context().source()[self.verbatim_range], ['\r']) {
	Cow::Borrowed(_) => {
	write!(f, [source_text_slice(self.verbatim_range)])?;
	}
	Cow::Owned(cleaned) => {
	text(&cleaned).fmt(f)?;
	}
	}
	f.write_element(FormatElement::Tag(Tag::EndVerbatim));
	Ok(())
	}
	}

and:

ruff/crates/ruff_formatter/src/format_element.rs

Lines 198 to 224 in 89d915a

	/// Replace the line terminators matching the provided list with "\n"
	/// since its the only line break type supported by the printer
	pub fn normalize_newlines<const N: usize>(text: &str, terminators: [char; N]) -> Cow<str> {
	let mut result = String::new();
	let mut last_end = 0;
	for (start, part) in text.match_indices(terminators) {
	result.push_str(&text[last_end..start]);
	result.push('\n');
	last_end = start + part.len();
	// If the current character is \r and the
	// next is \n, skip over the entire sequence
	if part == "\r" && text[last_end..].starts_with('\n') {
	last_end += 1;
	}
	}
	// If the result is empty no line terminators were matched,
	// return the entire input text without allocating a new String
	if result.is_empty() {
	Cow::Borrowed(text)
	} else {
	result.push_str(&text[last_end..text.len()]);
	Cow::Owned(result)
	}
	}

[dylwil3]

Ok I think I see what's happening?

The formatter writes the debug text "verbatim" by doing the following:

1. Write text that appears between the '{' and the expression node.
2. Write the expression node "verbatim" - which includes normalizing newlines.
3. Write the text that appears after the expression node and the '}'.

ruff/crates/ruff_python_formatter/src/other/interpolated_string_element.rs

Lines 178 to 185 in 89d915a

	write!(
	f,
	[
	text(&debug_text.leading),
	verbatim_text(&**expression),
	text(&debug_text.trailing),
	]
	)?;

In particular, any normalization is omitted for the leading and trailing whitespace.

Separately: I'm confused why we normalize given that we also have a line-ending option? Shouldn't we be using that?

[MichaReiser]

Pasting the example into Python gives us:

>>> f"{
...
... 1=
...
... }"
'\n\n1=\n\n1'

That means, normalizing the newlines is okay from a semantic point of view.

The formatter actually panics in debug builds with:

panicked at crates/ruff_formatter/src/builders.rs:405:5:
The content '
' contains an unsupported '\r' line terminator character but text must only use line feeds '\n' as line separator. Use '\n' instead of '\r' and '\r\n' to insert a line break in 

Separately: I'm confused why we normalize given that we also have a line-ending option? Shouldn't we be using that?

The formatter works in two stages:

1. Generate IR
2. Print the IR to a string

The 1. step is responsible for normalizing all newlines in text to \n because the step 2. doesn't support \r\n or \r to simplify many hot code paths. Step 2 is responsible for replacing all \n with the configured line ending.

Step 1 only rarely needs to normalize line endings because it uses the soft_line_break or hard_line_break IR elements most of the time. It's really just in multiline text elements where the normalization is required.

[MeGaGiGaGon]

From what I've seen, Python basically always normalizes newlines unless you call internal methods, which lets you get odd looking results like this

print(eval('ord("""\r\n""")')) # outputs 10 instead of error
print(eval('ord("""\r""")')) # outputs 10 instead of 13