[ruff] Fix panic when comments appear between unary operators and operands

[TaKO8Ki]

Summary

Fixes #19226

Fixes a panic in binary expression formatting caused by TextRange assertion failures when comments are positioned between unary operators (like not) and their operands.

The issue occurred because expression.start() points to the unary operator while comment.end() can be positioned after it, creating invalid TextRange where start > end. The fix uses operand.start() for unary operations to ensure proper ordering.

Test Plan

I have added new test cases to crates/ruff_python_formatter/resources/test/fixtures/ruff/expression/unary.py.

[github-actions]

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[MichaReiser]

Thank you. I need to think about whether this is the intended comment placement as it means that a comment can now move "forward" (it moves from after not to before not)

[TaKO8Ki]

@MichaReiser Ok. If it's not intentional, I can make has_lparen_between_comment_and_expression to skip unary.

[MichaReiser]

Sorry for the late reply.

I just took a look at which node the formatter associates the comment for:

if '' and (not #
0):
    pass

{
    Node {
        kind: ExprUnaryOp,
        range: 11..18,
        source: `not #⏎`,
    }: {
        "leading": [
            SourceComment {
                text: "#",
                position: EndOfLine,
                formatted: false,
            },
        ],
        "dangling": [],
        "trailing": [],
    },
}

To me, associating the comment as the leading comment of not seems incorrect, as it doesn't come before the unary not.

I'd either expect this to be a leading comment of 0, or a trailing comment of the unary expression.

An other alternative, and I think my preferred solution, is to make the comment a dangling comment of the unary expression instead. In fact, it seems we already have some handling for unary comments inside place_comment. Maybe all that is needed is to make that work for the given case?

ruff/crates/ruff_python_formatter/src/comments/placement.rs

Lines 1846 to 1872 in a1e3d93

	fn handle_unary_op_comment<'a>(
	comment: DecoratedComment<'a>,
	unary_op: &'a ast::ExprUnaryOp,
	source: &str,
	) -> CommentPlacement<'a> {
	let mut tokenizer = SimpleTokenizer::new(
	source,
	TextRange::new(unary_op.start(), unary_op.operand.start()),
	)
	.skip_trivia();
	let op_token = tokenizer.next();
	debug_assert!(op_token.is_some_and(|token| matches!(
	token.kind,
	SimpleTokenKind::Tilde
	| SimpleTokenKind::Not
	| SimpleTokenKind::Plus
	| SimpleTokenKind::Minus
	)));
	let up_to = tokenizer
	.find(|token| token.kind == SimpleTokenKind::LParen)
	.map_or(unary_op.operand.start(), |lparen| lparen.start());
	if comment.end() < up_to {
	CommentPlacement::leading(unary_op, comment)
	} else {
	CommentPlacement::Default(comment)
	}
	}