Indentation messes up in incredibly specific condition.

[bolshoytoster]

Consider the following 3 lines of code:

fn main() {
    let _ = 0. < 1.;
}

If you put your cursor at the end of line 2, then press enter, you'd expect the next line to be indented at the same level, however this happens:

fn main() {
    let _ = 0. < 1.;
                // It's indented to here
}

Also, if you do the same with the last line:

fn main() {
    let _ = 0. < 1.;
    }
    // Indented to here

This is because of the 0. < bit. If you change it to 0.0 < or 0. >, indentation works perfectly fine, so it's likely due to the combination of missing the decimal part and having the < character, which is also used as a bracket in rust.

I may have narrowed it down via a few hours of trial and error to this regex:

rust-mode/rust-mode.el

Line 629 in 22fff6a

(when (not (looking-at "[[:blank:]]*\\(?://.*\\)?$"))

Which does not match with the original code, but does with the fixed code.
I don't believe that this is the cause of the issue though, since I also found that in that match, for the working code it will match an empty string $ (expected, since the cursor is at the end of the line). For the original code however, it matches 1\.;$, and it's the exact same if I increase the line's length. This means that something has moved the cursor to just after the <.

I confirmed this by changing the < to [, the same thing happens.

It looks like this is done by this line:

rust-mode/rust-mode.el

Line 827 in 22fff6a

(backward-up-list)

Commenting that out means it only indents by one extra level, which is bearable. Unfortunately, this is a hack, and probably breaks another indentation feature.

The thing that confuses me is that backward-up-list only goes back to the < if the decimal part is left out. It's probably due to this regex:

rust-mode/rust-mode.el

Line 620 in 22fff6a

(defconst rust-re-pre-expression-operators "[-=!%&*/:<>[{(|.^;}]")

Which matches the ., assuming it's an operator. I managed to get the regex to work as intended for a few minutes, then I broke it again ([-=!%&*/:<>[{(|^;}]\\|[^[:digit:]]\\.). If somebody else more versed with lisp could help that would be great since I've run out of ideas.

If anyone else has this problem, a temporary solution is to replace rust-is-lt-char-operator:

rust-mode/rust-mode.el

Lines 1216 to 1262 in 22fff6a

	(defun rust-is-lt-char-operator ()
	"Return non-nil if the `<' sign just after point is an operator.
	Otherwise, if it is an opening angle bracket, then return nil."
	(let ((case-fold-search nil))
	(save-excursion
	(rust-rewind-irrelevant)
	;; We are now just after the character syntactically before the <.
	(cond
	;; If we are looking back at a < that is not an angle bracket (but not
	;; two of them) then this is the second < in a bit shift operator
	((and (rust-looking-back-str "<")
	(not (equal 4 (rust-syntax-class-before-point)))
	(not (rust-looking-back-str "<<"))))
	;; On the other hand, if we are after a closing paren/brace/bracket it
	;; can only be an operator, not an angle bracket. Likewise, if we are
	;; after a string it's an operator. (The string case could actually be
	;; valid in rust for character literals.)
	((member (rust-syntax-class-before-point) '(5 7 15)) t)
	;; If we are looking back at an operator, we know that we are at
	;; the beginning of an expression, and thus it has to be an angle
	;; bracket (starting a "<Type as Trait>::" construct.)
	((looking-back rust-re-pre-expression-operators (1- (point))) nil)
	;; If we are looking back at a keyword, it's an angle bracket
	;; unless that keyword is "self", "true" or "false"
	((rust-looking-back-symbols rust-keywords)
	(rust-looking-back-symbols '("self" "true" "false")))
	((rust-looking-back-str "?")
	(rust-is-in-expression-context 'ambiguous-operator))
	;; If we're looking back at an identifier, this depends on whether
	;; the identifier is part of an expression or a type
	((rust-looking-back-ident)
	(backward-sexp)
	(or
	;; The special types can't take type param lists, so a < after one is
	;; always an operator
	(looking-at rust-re-special-types)
	(rust-is-in-expression-context 'ident)))
	;; Otherwise, assume it's an angle bracket
	))))

with:

(defun rust-is-lt-char-operator () t)

[psibi]

Does this work with tree sitter: https://github.com/rust-lang/rust-mode?tab=readme-ov-file#tree-sitter ?