Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for stabilizing libcore #27871

Merged
merged 4 commits into from
Aug 22, 2015
Merged

Conversation

alexcrichton
Copy link
Member

These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:

  • The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
  • The core::atomic module now lives in core::sync::atomic. The core::sync module is otherwise empty, but ripe for expansion!
  • The core::prelude::v1 module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
  • Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the flt2dec module is now used for "privacy").

After this commit, the remaining large unstable functionality specific to libcore is:

  • raw, intrinsics, nonzero, array, panicking, simd -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
  • num::Float - this extension trait for floats needs to be audited for functionality (much of that is happening in Remove dependencies on libm functions from libcore. #27823) and may also want to be renamed to FloatExt or F32Ext/F64Ext.
  • Should the extension traits for primitives be stabilized in libcore?

I believe other unstable pieces are not isolated to just libcore but also affect the standard library.

cc #27701

All of the modules in the standard library were just straight reexports of those
in libcore, so remove all the "macro modules" from the standard library and just
reexport what's in core directly.
This mirrors the same hierarchy in the standard library.
@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@alexcrichton
Copy link
Member Author

r? @aturon

@@ -8,6 +8,10 @@
// option. This file may not be copied, modified, or distributed
// except according to those terms.

// this is in principle private which is only made public for testing. do not
// expose us in the documentation as a result
#![doc(hidden)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point of this? Nobody is ever going to generate docs for libcoretest.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh oops I thought this was libcore, looks like this already exists in libcore!

This commit stabilizes the prelude::v1 module of libcore after verifying that
it's a subset of the prelude of the standard library with the addition of a few
extension traits.
Stop using stability to hide the implementation details of ParseFloatError and
instead move the error type into the `dec2flt` module. Also move the
implementation blocks of `FromStr for f{32,64}` into `dec2flt` directly.
@aturon
Copy link
Member

aturon commented Aug 19, 2015

@bors: r+

@bors
Copy link
Contributor

bors commented Aug 19, 2015

📌 Commit a2b932c has been approved by aturon

@bors
Copy link
Contributor

bors commented Aug 22, 2015

⌛ Testing commit a2b932c with merge 94ee3b5...

bors added a commit that referenced this pull request Aug 22, 2015
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:

* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").


After this commit, the remaining large unstable functionality specific to libcore is:

* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823)  and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?

I believe other unstable pieces are not isolated to just libcore but also affect the standard library.

cc #27701
@bors bors merged commit a2b932c into rust-lang:master Aug 22, 2015
@alexcrichton alexcrichton deleted the stabilize-libcore branch September 3, 2015 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants