regenerate libcore/char_private.rs

[zackmdavis]

(filed separately from the work in #45569, because of this matter of the updated Unicode data; see also #45567)

char_private.rs is generated programmatically by char_private.py, using data retrieved from the Unicode Consortium's website.

The motivation here was to make is_printable crate-visible (with pub(crate)), but it would seem that the Unicode data has changed slightly since char_private.rs was last generated.

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[estebank]

Sorry for the wide spam, @rust-lang/core, @rust-lang/libs, @rust-lang/docs not sure who to ask this.

This change will update Rust's unicode support from 9 to 10, IIUC. Is this something that can be updated matter of fact without an RFC? I'm inclined to r+ it, maybe changing the PR's name beforehand to make sure it's not lost in the shuffle in the corresponding release's notes.

[kennytm]

@estebank We should be already using Unicode 10 (#42999)...

Similar previous PRs (e.g. upgrade entirely to Unicode 9 #34599) don't have RFCs, but they don't pass as a single-handed r+ either.

However, the char_private module only defines the is_printable function, which in turn is only used in char::escape_debug that has no stability guarantee on the Unicode version. So I guess it is fine to merge without deep inspection.

[alexcrichton]

@bors: r+

Thanks for the extra info @kennytm!

[bors]

📌 Commit 3c81d3d has been approved by alexcrichton

[kennytm]

(I've removed the relnotes tag since it only affects escape_debug which doesn't seem to be a big point to mention.)

[bors]

⌛ Testing commit 3c81d3d with merge a17e724...

[Mark-Simulacrum]

I disagree - I think this change is worth mentioning in the compatibility section of the relnotes.

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing a17e724 to master...