Merge the std_unicode crate into the core crate #49698
Conversation
SimonSapin
added
A-Unicode
|
@rfcbot fcp merge |
|
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
the
proposed-final-comment-period
|
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Looks great to me, thanks @SimonSapin! |
SimonSapin
force-pushed
the
unicode-for-everyone
branch
2 times, most recently
from
03146b4
to
82c1812
Compare
|
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Why are we doing this? Moving creates beneath the facade into |
|
More broadly, I've argued with I believe some sucesss in the portability working group that the facade is actually useful, but I'm worried that with PRs like this that viewpoint isn't making it back out. This PR is fine if the working presumption is the facade is bad, but only that is true. |
|
The questions of whether the All this is saying is that the |
|
@SimonSapin I don't really believe Other than extension traits being mildly ugly, what benefits does this PR bring? Alternatively could this create go on |
|
@Ericson2314 do you have a valid reason why This isn't a manner of assuming that a system has less; it's a manner of simply assuming that the programmer wants Unicode support, which I feel isn't a very great assumption considering how LTO is enabled by default on release and that it takes very little effort to avoid including these unicode tables in an executable or library. Also, I'd like to counter the "dumping ground" argument; the standard library is intended to hold things which are either a) hard to maintain without compiler support or b) so fundamental that it'll show up in most programs. |
|
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
SimonSapin
force-pushed
the
unicode-for-everyone
branch
from
dcc1094
to
d381b3f
Compare
|
@clarcharr I think big creates are harder to maintain, especially for people that have never worked on them before. I also think out of tree creates are easier to maintain because people can build them like any other crate.
I agree that a bigger core is not a problem compile time wise or whatever, just as you both.
I also agree the not-wanting unicode case is not worth considering. But I don't think it's good code organization to put everything that's "free and always wanted" in core.
I absolutely agree that's sort of probablem we should care about with this, unlike the others which we agree are non-pronkems. But I think moving to rust-lang-nursery and creates.io is the best solution.
I'm fine with that and agree that this fits, as does libc. The difference is I view "being in the standard library" and "being in rust-lang/rust" as two different things. I want to limit library code in rust-lang/rust to your a), code that is tightly integrated with rustc. Anything that's stable Rust however can evolve better separately out of tree. I'd love somebody, maybe me, to do an analysis on rand/libc development before and after moving out of tree. We can judge my argument empirically. |
|
@Ericson2314 Most of these are inherent methods on Like I get the sentiment but I think what you're addressing is much larger than this PR. |
|
I did a very bad job at explaining the connection with the portability stuff on IRC to @SimonSapin. Yes, this PR doesn't matter directly because this library is already quite portable. But it does generally bare on the weirdness of No one here actually said std deps on crates.io was weird, but at least @clarcharr's comment sort of presumed a hard "standard library" vs "rest of ecosystem" distinction, which std deps on crates.io blurs. I want to advocate for that blurring being a good thing, and point out that for portability's sake it may happen anyways (with other crates). |
That ship has sailed. The relevant functionality is stable and reexported in libstd, some of it since Rust 1.0. |
|
Huh? Std already depends on out of tree crates as I've said repeatedly. I don't understand your point. |
|
My point is that we can’t just remove the And this PR is all about how we expose functionality in the public API (e.g. do |
|
@Ericson2314 it seems to me like you want to have a larger conversation about how we handle the organization of libstd (moving things out of tree etc). That's fine, but it seems off topic from this PR, which is about the smaller and largely unrelated question of making the unicode APIs easily available from libcore. |
And the UnicodeStr trait into StrExt
SimonSapin
force-pushed
the
unicode-for-everyone
branch
from
a278a81
to
ef41788
Compare
|
Still the same @bors r=alexcrichton |
|
📌 Commit ef41788 has been approved by |
Merge the std_unicode crate into the core crate [The standard library facade](#27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](#42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers. This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly. A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd. Fixes #49319.
|
☀️ Test successful - status-appveyor, status-travis |
Tested on commit rust-lang/rust@d26f9e4. Direct link to PR: <rust-lang/rust#49698> 💔 rls on windows: test-pass → build-fail (cc @nrc). 💔 rls on linux: test-pass → build-fail (cc @nrc). 💔 rustfmt on windows: test-pass → build-fail (cc @nrc). 💔 rustfmt on linux: test-pass → build-fail (cc @nrc).
Char.len_utf8 is stable since rust-lang#49698, making this a little easier to follow.
library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
Rollup merge of rust-lang#132482 - lukas-code:stab-attrs, r=Noratrieb library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
The standard library facade has historically contained a number of crates with different roles, but that number has decreased over time.
randandlibchave moved to crates.io, andcollectionswas merged intoalloc. Today we havecorethat applies everywhere,stdthat expects a full operating system, andallocin-between that only requires a memory allocator (which can be provided by users)… andstd_unicode, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers.This deprecates the unstable
std_unicodecrate and moves all of its contents intocore, replacing them withpub usereexports. The crate can be removed later. This also removes theCharExttrait (replaced with inherent methods in libcore) andUnicodeStrtrait (merged intoStrExt). There traits were both unstable and not intended to be used or named directly.A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd.
Fixes #49319.