[riki-nishida]

Fixes #863.

Problem

debug_non_utf8_classname registers a class whose name contains invalid UTF-8 (My\xF0\x90\x80Class), and compares the Debug output of an instance against a hardcoded string. -description decodes the name using the system text encoding, but the hardcoded string is what you get with MacRoman, so the test fails on machines that use a different encoding, such as when the system language is set to Japanese:

  left: "<My\u{e04f}\\Class: 0x10571caf0>"
 right: "<My\u{f8ff}êÄClass: 0x10571caf0>"

Fix

Build the expected class name from [cls description] instead, which is decoded the same way. Since this only changes a test, I didn't add a changelog entry.

Testing

On macOS 26.6.2 (Aarch64), cargo test -p objc2 --lib debug_non_utf8_classname passes with __CF_USER_TEXT_ENCODING set to MacRoman, Japanese, Traditional Chinese, Korean, Cyrillic and Simplified Chinese. Without the fix, it fails with everything except MacRoman, and I also confirmed that switching the system language between Japanese and English changes the result.

The rest of cargo test -p objc2 passes with MacRoman and Japanese, as do cargo fmt -- --check and cargo clippy -p objc2 --all-targets.

[madsmtm]

Thanks!