Yan Li

Thanks @terhechte! That looks promising, I will try to compile a toolchain for the triple and see if I can build a binary for `x86_64-apple-ios-macabi`.

I've tried to build a toolchain for `x86_64-apple-ios-macabi`, and linked it to rustup. ``` ./x.py build --target=x86_64-apple-ios-macabi rustup toolchain link mytoolchain build/x86_64-apple-darwin/stage2/ ``` Then I tried to build and test...

I'm having a similar issue when linking a `x86_64` static library produced by `cargo build` in a macOS application, the error message was with the same format and I can...

I'm in a similar position with you too: I have a Unicode tool in production and need to keep the data of the app up-to-date (currently Unicode 13.0). So far...

> Time for Unicode 15.0 :( > > I'm... trying to help implementing [rust-lang/rust#101840](https://github.com/rust-lang/rust/issues/101840) . Currently `rustc` is relying on `unic_emoji_char::is_emoji` for diagnostics. But it seems the Unicode data here...

My fork current has these changes: - A new module for Unihan (data updated to Unicode 14.0) - Unicode 11.0 data changes and segmentation algorithm changes - Unicode 12.0 and...

Looks like there might be a bug when generating https://github.com/open-i18n/rust-unic/blob/master/unic/emoji/char/tables/emoji.rsv#L6 so that U+0030..U+0039 were mistakenly extracted out from the original UCD file (https://github.com/open-i18n/data-unicode-ucd/blob/master/data/EmojiSources.txt). I believe U+0030..U+0039 are only considered as...

I believe the cause is that https://github.com/open-i18n/rust-unic/blob/master/gen/src/source/emoji/emoji_data.rs#L54 reuses the regex for parsing other binary properties (`source::ucd::BINARY_PROPERTIES_REGEX`) however the UCD file for emoji sources has a slightly different format (or rather...

Please refer to #225 for a possible way to implement this.

Sure, wait for the external sources sounds like a better option 👍