Do not consider f-strings with escaped newlines as multiline

[dhruvmanila]

Summary

This PR fixes a bug in the f-string formatting to not consider the escaped newlines for is_multiline. This is done by checking if the f-string is triple-quoted or not similar to normal string literals.

This is not required to be gated behind preview because the logic change for is_multiline was added in #14454.

Test Plan

Add a test case which formats differently on main: https://play.ruff.rs/ea3c55c2-f0fe-474e-b6b8-e3365e0ede5e

[github-actions]

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[MichaReiser]

This is not required to be gated behind preview because the logic change for is_multiline was added in #14454.

I'm not sure I understand this part. Isn't the reason why no preview gating is required because this new logic is only used in preview mode?

[dhruvmanila]

Isn't the reason why no preview gating is required because this new logic is only used in preview mode?

The is_multiline is also used in binary expression formatting which isn't gated behind preview. You can see that in the playground by turning off the preview flag: https://play.ruff.rs/8ef99e9b-ea54-44b4-a483-f7339424865d. The logic for f-strings was changed from just checking for newlines in the entire f-string to checking individual elements in the linked PR.

[MichaReiser]

Looking at #14454 is_multiline again, I think the change we made there has a high potential for unwanted stable style changes. We should change the is_multiline to keep using the "old" memchr2(b'\n', b'\r', source[fstring.range].as_bytes()).is_some() if f-string formatting is disabled and only use the new logic if f-string formatting is enabled. We otherwise risk that bugs like the one you found here impact stable style users.

[MichaReiser]

Could we add some tests in assignment positions and with implicit concatenated strings (especially with inline comments) just to make sure strings with line continuations are handled correctly in those positions too

[dhruvmanila]

Adding these test case reveals one more change in implicitly concatenated strings. Given:

f"hellooooooooooooooooooooooo \
        worldddddddddddddddddd" "another string"

On main, we don't concatenate it because the f-string is considered as multiline but here we would. I'm going to make the is_multiline change gated behind preview first, rebase this PR and add the test cases.

[MichaReiser]

I think concatenating the string makes sense as long as it fits into the line length

[dhruvmanila]

I think the change we made there has a high potential for unwanted stable style changes. We should change the is_multiline to keep using the "old" memchr2(b'\n', b'\r', source[fstring.range].as_bytes()).is_some() if f-string formatting is disabled and only use the new logic if f-string formatting is enabled. We otherwise risk that bugs like the one you here impact users of our stable style.

I see, I think that makes sense. I'll do that as a follow-up.