https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.4.0 2015-09-07T22:36:29+00:00 2015-09-07T22:36:29+00:00 Andre Bogus bogusandre@gmail.com 2015-09-07T22:36:29+00:00 urn:sha1:9cca96545faf2cfc972cc67b83deae2a78935c43 2015-08-22T09:59:07+00:00 bors bors@rust-lang.org 2015-08-22T09:59:07+00:00 urn:sha1:94ee3b5a54a9f4965b82f5e4eda512966e96ac63 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 2015-08-20T00:01:19+00:00 Steven Fackler sfackler@gmail.com 2015-08-20T00:01:19+00:00 urn:sha1:12216b7209431ae2a53d52c3a41c0d3536ab2210 2015-08-20T00:00:15+00:00 Steven Fackler sfackler@gmail.com 2015-08-19T22:00:11+00:00 urn:sha1:b1c7a46c0db2cd73575792aebe08108b53289d80 2015-08-20T00:00:15+00:00 Steven Fackler sfackler@gmail.com 2015-08-15T03:35:33+00:00 urn:sha1:46156de5f1d8a4ebfb874d170ba6844462b5781b 2015-08-20T00:00:15+00:00 Steven Fackler sfackler@gmail.com 2015-08-14T04:58:20+00:00 urn:sha1:42a386fcf89a40e6c3a8806ccf381514c2a77c10 Returning a primitive bool results in a somewhat confusing API - does `true` indicate success - i.e. no timeout, or that a timeout has occurred? An explicitly named enum makes it clearer. [breaking-change] 2015-08-17T21:03:32+00:00 Alex Crichton alex@alexcrichton.com 2015-08-17T20:56:55+00:00 urn:sha1:0c849de1a2bad4b63b15b0155ecef8758f5211e5 This mirrors the same hierarchy in the standard library. 2015-08-16T01:09:17+00:00 Alex Crichton alex@alexcrichton.com 2015-08-13T17:12:38+00:00 urn:sha1:5f625620b5e4e29919400a0ee863942e5bf3d970 2015-08-14T15:26:09+00:00 bors bors@rust-lang.org 2015-08-14T15:26:09+00:00 urn:sha1:e7261f3ab60e0d1e6c808004ecd25c88e04f3683 This PR implements the majority of RFC 1214. In particular, it implements: - the new outlives relation - comprehensive WF checking For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run. There are some deviations from RFC 1214. Most notably: - we still consider implied bounds from fn ret; this intersects other soundness issues that I intend to address in detail in a follow-up RFC. Fixing this without breaking a lot of code probably requires rewriting compare-method somewhat (which is probably a good thing). - object types do not check trait bounds for fear of encountering `Self`; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent. Both of those two issues are highlighted in the tracking issue, https://github.com/rust-lang/rust/issues/27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests. r? @nrc (or perhaps someone else?) 2015-08-12T21:58:56+00:00 Niko Matsakis niko@alum.mit.edu 2015-08-07T13:27:27+00:00 urn:sha1:91b3e9cac0125e35d65169fb7e06166a078296c7