fix versionsort chunk split on non-ASCII numerics

[jessicarod7]

Description

Fixes a bug with 2024 Edition versionsort, where a string chunk will split on all numeric characters. For example, this would cause imports containing non-ASCII numeric characters to be incorrectly sorted.

Unformatted (Playground link):

use std::cmp::Ordering;
use print๙msg::print as first_print;
use print0msg::print as second_print;
use printémsg::print as third_print;

fn main() {
    first_print();
    second_print();
    third_print();

    assert_eq!("print๙msg".cmp("printémsg"), Ordering::Greater);
}

/// '๙' = 0E59;THAI DIGIT NINE;Nd;
mod print๙msg {
    pub fn print() {
        println!("Non-ASCII Decimal_Number")
    }
}

/// '0' = 0030;DIGIT ZERO;Nd;
mod print0msg {
    pub fn print() {
        println!("ASCII Decimal_Number")
    }
}

/// 'é' = 00E9;LATIN SMALL LETTER E WITH ACUTE;Ll;
mod printémsg {
    pub fn print() {
        println!("Lowercase_Letter")
    }
}

Formatted imports (nightly 2024-11-29, Playground link):

use print0msg::print as second_print;
use print๙msg::print as first_print;
use printémsg::print as third_print;
use std::cmp::Ordering;

Here, printémsg should be sorted before print๙msg, but since ๙ is a non-ASCII numeric, that import is split into two short string chunks, which will sort before the one longer chunk.

Changes & Notes

• Replaces a char::is_numeric() check with the correct char::is_ascii_digit() call in VersionChunkIter::parse_str_chunk().
• I also ran the updated rustfmt against the repo and found no changes, so there isn't a separate commit for that.
• Related to tracking issue Tracking Issue for Rust 2024: rustfmt use version sort rust#123800

[ytmimi]

The Style Guide mentions that numeric chunks are defined by ascii digits so using is_ascii_digit is definitely the right function call to use.

I've left a few comments inline. I think we should rework the current test case and also add a style_edition=2015 case so that we can compare the sort order when dealing with non ascii numeric characters.

[ytmimi]

Let's remove any code that isn't an import since it's not needed for the test case. Though, It would be great to keep the explanatory comments you added about '๙', '0', and 'é' to help document the test case.

[jessicarod7]

Updated and expanded on the comments to explain why they sort in that order.

[ytmimi]

version sort is only be applied when using style_edition=2024. You'll need to configure that for this test as follows:

Suggested change

	use std::cmp::Ordering;
	use print๙msg::print as first_print;
	use print0msg::print as second_print;
	use printémsg::print as third_print;
	// rustfmt-style_edition: 2024
	use std::cmp::Ordering;
	use print๙msg::print as first_print;
	use print0msg::print as second_print;
	use printémsg::print as third_print;

You can read more about the comment configuration in test cases here.

Also, can you also add a style_edition=2015 import sorting test case so that we can compare the pre version sort ordering.

[jessicarod7]

Added. The 2015 edition actually sorts the same way since U+0030 < U+00E9 < U+0E59, so the bug only affected 2024 edition (and can't be reproduced on earlier versions because ASCII digits are the earliest Unicode numerics).

[ytmimi]

Thanks for adding that additional test case!

[ytmimi]

Thanks for your help on this one!

[ytmimi]

I think we're good to go here, but just want to do a quick sanity check by running the updated rustfmt on some larger rust codebases. Here's a link to the diff check job.

Edit: Job ran successfully ✅

[calebcartwright]

@ytmimi - I was trying to determine whether we needed to account for this one in the release notes and have two questions:

• Is it accurate to say that we believe this fix, though a change to formatting behavior in this very narrow context, remains aligned with the stability guarantee due to the clause around non-ascii unicode characters? (https://github.com/rust-lang/rustfmt?tab=readme-ov-file#limitations)
• I see you removed the label on Jan 1st, is that because the notes have already been accounted for somewhere?

[ytmimi]

• Is it accurate to say that we believe this fix, though a change to formatting behavior in this very narrow context, remains aligned with the stability guarantee due to the clause around non-ascii unicode characters? (https://github.com/rust-lang/rustfmt?tab=readme-ov-file#limitations)

The way I see it, yes, this change is aligned with the clause around non-ascii unicode characters.

• I see you removed the label on Jan 1st, is that because the notes have already been accounted for somewhere?

I opened #6432 to get the ball rolling on the release notes and removed the label for anything that I already added to that draft PR. I made a note here specifically for this change.