Line width computation in the linter and formatter

[dhruvmanila]

Related to #12130, it turns out that computing the line width on a char-by-char basis and as a whole str is different. From the docs of unicode-width, it's these cases where it differs specifically.

In the linter, the LineWidthBuilder determines the width by looking at each char individually. But, in some places the width is computed directly on &str which creates the panic as in #12130. These cases are:

ruff/crates/ruff_linter/src/rules/pycodestyle/overlong.rs

Line 64 in eeb24b1

if width.get() - last_chunk.width() <= limit.value() as usize {

ruff/crates/ruff_linter/src/rules/isort/sorting.rs

Line 109 in eeb24b1

.then_some(name.map(str::width).unwrap_or_default() + level as usize);

ruff/crates/ruff_linter/src/rules/isort/sorting.rs

Line 160 in eeb24b1

let maybe_length = settings.length_sort.then_some(name.width());

ruff/crates/ruff_linter/src/fix/snippet.rs

Lines 35 to 39 in eeb24b1

	/// Returns `true` if the source code should be truncated when included in a user-facing
	/// diagnostic.
	fn should_truncate(source_code: &str) -> bool {
	source_code.width() > 50 || source_code.contains(['\r', '\n'])
	}

In the formatter,

ruff/crates/ruff_formatter/src/printer/mod.rs

Lines 845 to 846 in eeb24b1

	// SAFETY: A u32 is sufficient to represent the width of a file <= 4GB
	char.width().unwrap_or(0) as u32

ruff/crates/ruff_formatter/src/printer/mod.rs

Lines 1520 to 1522 in eeb24b1

	// SAFETY: A u32 is sufficient to format files <= 4GB
	#[allow(clippy::cast_possible_truncation)]
	c => c.width().unwrap_or(0) as u32,

[dhruvmanila]

I'll close this as resolved by #12135 but this is a good reference to have for the time being.