Handle non-ascii character at boundary

[scampi]

Close #5023

[scampi]

With the non-ascii character at the boundary, the value of max_width_index_in_input is 0. The proposed fix avoids the overflow.
However, I wonder if I should instead amend the algorithm that updates max_width_index_in_input so that it doesn't return 0.

rustfmt/src/string.rs

Lines 269 to 280 in 76d626f

	let max_width_index_in_input = {
	let mut cur_width = 0;
	let mut cur_index = 0;
	for (i, grapheme) in input.iter().enumerate() {
	cur_width += unicode_str_width(grapheme);
	cur_index = i;
	if cur_width > max_width {
	break;
	}
	}
	cur_index
	};

[calebcartwright]

Yeah I was thinking that this should address the reported issue but was wondering if these types of characters appeared in different positions if it could still make us split in the wrong location.

I'd be okay moving ahead with this given the immediate relief it would provide, and consider a broader fix in a follow up PR. Happy to park on this though if you want to experiment with a different approach though

[scampi]

@calebcartwright I don't find a way to fix the computation of max_width_index_in_input, but I have replaced the previous fix with an early termination check. I think that makes the rest cleaner, knowing that max_width_index_in_input is at least 1.

[calebcartwright]

Agreed, seems like a reasonable approach for now and certainly addresses the pressing issue at hand 👍