Commit Graph

297 Commits

Author SHA1 Message Date
Guillaume Gomez
86bf3ce859
Rollup merge of #75644 - c410-f3r:array, r=yaahc
Add 'core::array::from_fn' and 'core::array::try_from_fn'

These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`.

```rust
// Foo doesn't implement Default
struct Foo(usize);

let _array = core::array::from_fn::<_, _, 2>(|idx| Foo(idx));
```

Different from `FromIterator`, it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios, however, the creation of an **element** can fail and that is why the `try_from_fn` function is also provided.

```rust
#[derive(Debug, PartialEq)]
enum SomeError {
    Foo,
}

let array = core::array::try_from_fn(|i| Ok::<_, SomeError>(i));
assert_eq!(array, Ok([0, 1, 2, 3, 4]));

let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo));
assert_eq!(another_array, Err(SomeError::Foo));
 ```
2021-10-09 17:08:38 +02:00
Caio
85c4a52807 Also cfg flag auxiliar function 2021-10-08 06:40:24 -03:00
Jane Lusby
8965b5884a
Revert "Stabilize Iterator::intersperse()" 2021-10-07 10:39:36 -07:00
Manish Goregaokar
4e8c853c9e
Rollup merge of #89502 - FabianWolff:issue-89493, r=joshtriplett
Fix Lower/UpperExp formatting for integers and precision zero

Fixes the integer part of #89493 (I daren't touch the floating-point formatting code). The issue is that the "subtracted" precision essentially behaves like extra trailing zeros, but this is not currently reflected in the code properly.
2021-10-05 12:52:46 -07:00
Jubilee
ca8a10845f
Rollup merge of #87091 - the8472:more-advance-by-impls, r=joshtriplett
implement advance_(back_)_by on more iterators

Add more efficient, non-default implementations for `feature(iter_advance_by)` (#77404) on more iterators and adapters.

This PR only contains implementations where skipping over items doesn't elide any observable side-effects such as user-provided closures or `clone()` functions. I'll put those in a separate PR.
2021-10-04 13:58:07 -07:00
Manish Goregaokar
287af0403a
Rollup merge of #86828 - lambinoo:67441-const-fn-copied-take-replace, r=joshtriplett
const fn for option copied, take & replace

Tracking issue: [#67441](https://github.com/rust-lang/rust/issues/67441)

Adding const fn for the copied, take and replace method of Option. Also adding necessary unit test.

It's my first contribution so I am pretty sure I don't know what I'm doing but there's a first for everything!
2021-10-03 23:13:16 -07:00
Josh Triplett
199b33f0d7
Use a test value that doesn't depend on the handling of even/odd rounding 2021-10-03 20:15:12 -07:00
Fabian Wolff
e3996ffcb6 Fix Lower/UpperExp formatting for integers and precision zero 2021-10-03 23:05:03 +02:00
Caio
91ad91efb6 Skip platforms without unwinding support 2021-10-03 12:25:23 -03:00
Albin Hedman
81bb5a54c3
Revert "Auto merge of #86853 - usbalbin:const_try, r=oli-obk"
This reverts commit c6007fdc70, reversing
changes made to 69c1c6a173.
2021-10-02 00:07:48 +02:00
The8472
2c6e67105e implement advance_(back_)_by on more iterators 2021-09-30 21:23:28 +02:00
Caio
4be574e6c9 Add 'core::array::from_fn' and 'core::array::try_from_fn' 2021-09-30 07:49:32 -03:00
bors
c6007fdc70 Auto merge of #86853 - usbalbin:const_try, r=oli-obk
Constify ?-operator for Result and Option

Try to make `?`-operator usable in `const fn` with `Result` and `Option`, see #74935 . Note that the try-operator itself was constified in #87237.

TODO
* [x] Add tests for const T -> T conversions
* [x] cleanup commits
* [x] Remove `#![allow(incomplete_features)]`
* [?] Await decision in #86808 - I'm not sure
* [x] Await support for parsing `~const` in bootstrapping compiler
* [x] Tracking issue(s)? - #88674
2021-09-30 10:35:24 +00:00
bors
f06f9bbd3a Auto merge of #88999 - Migi:master, r=oli-obk
Make `Duration` respect `width` when formatting using `Debug`

When printing or writing a `std::time::Duration` using `Debug` formatting, it previously completely ignored any specified `width`. This is unlike types like integers and floats, which do pad to `width`, for both `Display` and `Debug`, though not all types consider `width` in their `Debug` output (see e.g. #30164). Curiously, `Duration`'s `Debug` formatting *did* consider `precision`.

This PR makes `Duration` pad to `width` just like integers and floats, so that
```rust
format!("|{:8?}|", Duration::from_millis(1234))
```
returns
```
|1.234s  |
```

Before you ask "who formats `Debug` output?", note that `Duration` doesn't actually implement `Display`, so `Debug` is currently the only way to format `Duration`s. I think that's wrong, and `Duration` should get a `Display` implementation, but in the meantime there's no harm in making the `Debug` formatting respect `width` rather than ignore it.

I chose the default alignment to be left-aligned. The general rule Rust uses is: numeric types are right-aligned by default, non-numeric types left-aligned. It wasn't clear to me whether `Duration` is a numeric type or not. The fact that a formatted `Duration` can end with suffixes of variable length (`"s"`, `"ms"`, `"µs"`, etc.) made me lean towards left-alignment, but it would be trivial to change it.

Fixes issue #88059.
2021-09-24 15:22:26 +00:00
Josh Triplett
3ece63b64e Temporarily rename int_roundings functions to avoid conflicts
These functions are unstable, but because they're inherent they still
introduce conflicts with stable trait functions in crates. Temporarily
rename them to fix these conflicts, until we can resolve those conflicts
in a better way.
2021-09-22 13:56:01 -07:00
Maybe Waffle
71e2eacc7b Stabilize Iterator::map_while 2021-09-17 19:42:46 +03:00
Michiel De Muynck
77ceb2b5d8 Make Duration's Debug format pad to width
Duration's Debug formatting previously ignored the width parameter.
This commit fixes that.

Fixes issue #88059.
2021-09-16 03:09:31 +02:00
Albin Hedman
3051bb9c81
Move tests to library/core/tests 2021-09-15 16:58:02 +02:00
Fabian Wolff
79adda930f Ignore automatically derived impls of Clone and Debug in dead code analysis 2021-09-09 19:49:07 +02:00
Falk Hüffner
d760c33183 Change return type for T::{log,log2,log10} to u32. The value is at
most 128, and this is consistent with using u32 for small values
elsewhere (e.g. BITS, count_ones, leading_zeros).
2021-09-05 17:09:21 +02:00
Mara Bos
80b572b5e5
Rollup merge of #88507 - atsuzaki:slice-fill-maybeuninit-test, r=RalfJung
Add test case for using `slice::fill` with MaybeUninit

Adds test for #87891

Looks alright? `@RalfJung`
Fixes #87891
2021-09-03 13:30:47 +02:00
Mara Bos
2159c5db63
Rollup merge of #88582 - jhpratt:int_roundings, r=joshtriplett
Implement #88581

See #88581 for details. This API was discussed on Zulip.

`@rustbot` label: +T-libs-api +S-waiting-on-review

r? `@joshtriplett`
2021-09-02 19:10:22 +02:00
Jacob Pratt
727a4fc7e3
Implement #88581 2021-09-02 01:53:54 -04:00
Mara Bos
d31352961c
Rollup merge of #88551 - inquisitivecrystal:unsafe_cell_raw_get, r=m-ou-se
Stabilize `UnsafeCell::raw_get()`

This PR stabilizes the associated function `UnsafeCell::raw_get()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/66358#issuecomment-899095068). While there was some discussion about the naming after the close of the FCP, it looks like people have agreed on this name. Still, it would probably be best if a `libs-api` member had a look at this and stated whether more discussion is needed.

While I was at it, I added some tests for `UnsafeCell`, because there were barely any.

Closes #66358.
2021-09-01 09:23:31 +02:00
inquisitivecrystal
227e004d3f Add a few tests for UnsafeCell 2021-08-31 16:32:01 -07:00
inquisitivecrystal
06dd4c03a0 Stabilize Iterator::intersperse() 2021-08-31 14:50:18 -07:00
Katherine Philip
5390ea4644 Move to the top of file 2021-08-31 08:28:51 -07:00
Katherine Philip
8cecac2602 Add test case for using slice::fill with MaybeUninit 2021-08-30 13:20:11 -07:00
Lamb
10ddabc194
const fn for option copied, take & replace + tests
fix: move test that require mut to another

Adding TODOs for Option::take and Option::copied

TODO to FIXME + moving const stability under normal

Moving const stability attr under normal stab attr

move more rustc stability attributes
2021-08-29 13:19:17 +02:00
ibraheemdev
58f988fa40 move object safety test to library/core 2021-08-15 13:00:25 -04:00
Yuki Okushi
9d21b5a39d
Rollup merge of #87876 - lcnr:windows_no_panic, r=m-ou-se
add `windows` count test

cc #87767
2021-08-11 04:18:43 +09:00
Yuki Okushi
bdc92f10e7
Rollup merge of #87636 - Kixiron:unzip-option, r=scottmcm
Added the `Option::unzip()` method

* Adds the `Option::unzip()` method to turn an `Option<(T, U)>` into `(Option<T>, Option<U>)` under the `unzip_option` feature
* Adds tests for both `Option::unzip()` and `Option::zip()`, I noticed that `.zip()` didn't have any
* Adds `#[inline]` to a few of `Option`'s methods that were missing it
2021-08-11 04:18:34 +09:00
Chase Wilson
9d8081e8b6
Enabled unzip_option feature for core tests & unzip docs 2021-08-09 10:24:02 -05:00
Chase Wilson
eea3520a8f
Added some basic tests for Option::unzip() and Option::zip() (I noticed that zip had no tests) 2021-08-09 10:24:00 -05:00
lcnr
24aa45c95e add windows count test 2021-08-09 11:08:39 +02:00
Albin Hedman
c8bf5ed628
Add test for int to float 2021-08-07 19:03:34 +02:00
Albin Hedman
09928a9a20
Add tests 2021-08-07 19:03:33 +02:00
bors
effea9a2a0 Auto merge of #87689 - JohnTitor:rollup-ns38b56, r=JohnTitor
Rollup of 13 pull requests

Successful merges:

 - #86183 (Change environment variable getters to error recoverably)
 - #86439 (Remove `Ipv4Addr::is_ietf_protocol_assignment`)
 - #86509 (Move `os_str_bytes` to `sys::unix`)
 - #86593 (Partially stabilize `const_slice_first_last`)
 - #86936 (Add documentation for `Ipv6MulticastScope`)
 - #87282 (Ensure `./x.py dist` adheres to `build.tools`)
 - #87468 (Update rustfmt)
 - #87504 (Update mdbook.)
 - #87608 (Remove unused field `Session.system_library_path`)
 - #87629 (Consistent spelling of "adapter" in the standard library)
 - #87633 (Update compiler_builtins to fix i128 shift/mul on thumbv6m)
 - #87644 (Recommend `swap_remove` in `Vec::remove` docs)
 - #87653 (mark a UB doctest as no_run)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-08-02 02:33:16 +00:00
Yuki Okushi
87c143661c
Rollup merge of #87629 - steffahn:consistent_adapter_spelling, r=m-ou-se
Consistent spelling of "adapter" in the standard library

Change all occurrences of "(A|a)daptor" to "(A|a)dapter".

The spelling “adapter” seems to be significantly more common both in general in the English language and also in the `rust` repository and standard library. I don’t like the inconsistency that’s currently found on pages like https://doc.rust-lang.org/std/iter/trait.Iterator.html. Note however that the Rust book consistently uses the spelling “iterator adaptor”.

Related discussion [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/adapter.20.2F.20adaptor) ([in the archive](https://zulip-archive.rust-lang.org/219381tlibs/60284adapteradaptor.html)).

`@rustbot` label T-libs
2021-08-02 11:03:28 +09:00
bors
24bbf7ac2f Auto merge of #85272 - ChayimFriedman2:matches-leading-pipe, r=m-ou-se
Allow leading pipe in `matches!()` patterns.

This is allowed in `match` statement, and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.
2021-08-02 00:13:40 +00:00
Frank Steffahn
8d2bb9389a Consistent spelling of "adapter" in the standard library
Change all occurrences of "(A|a)daptor" to "(A|a)dapter".
2021-07-30 17:23:07 +02:00
Tim Vermeulen
5e90909f38 Add tests 2021-07-22 22:05:41 +02:00
bors
fabf502a7a Auto merge of #87168 - the8472:flatten-len, r=scottmcm
implement TrustedLen for Flatten/FlatMap if the U: IntoIterator == [T; N]

This only works if arrays are passed directly instead of array iterators
because we need to be sure that they have not been advanced before
Flatten does its size calculation.

resolves #87094
2021-07-20 23:47:48 +00:00
bors
f502bd3abd Auto merge of #86761 - Alexhuszagh:master, r=estebank
Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.

# Summary

Rust, although it implements a correct float parser, has major performance issues in float parsing. Even for common floats, the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust).

Recently, major advances in float-parsing algorithms have been developed by Daniel Lemire, along with others, and implement a fast, performant, and correct float parser, with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](0e2b5d163d/data/canada.txt) dataset, 10x faster than Rust's 130 MiB/s.

In addition, [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](868c702d0c/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct, but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf), which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm, respectively.

Finally, this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed, due to use of the `Big32x40`, which simply does not have enough digits to round a float correctly. Using a custom decimal class, with much simpler logic, we can parse all valid decimal strings of any digit count.

```rust
// Issue in Rust's dec2fly.
"2.47032822920623272088284396434110686182e-324".parse::<f64>();   // Err(ParseFloatError { kind: Invalid })
```

# Solution

This pull request implements the Eisel-Lemire algorithm, modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT), along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core.

**Documentation**

Extensive documentation has been added to ensure the code base may be maintained by others, which explains the algorithms as well as various associated constants and routines. For example, two seemingly magical constants include documentation to describe how they were derived as follows:

```rust
    // Round-to-even only happens for negative values of q
    // when q ≥ −4 in the 64-bit case and when q ≥ −17 in
    // the 32-bitcase.
    //
    // When q ≥ 0,we have that 5^q ≤ 2m+1. In the 64-bit case,we
    // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case,we have
    // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10.
    //
    // When q < 0, we have w ≥ (2m+1)×5^−q. We must have that w < 2^64
    // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case)
    // or 2m+1 > 2^24 (32-bit case). Hence,we must have 2^53×5^−q < 2^64
    // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11
    // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase).
    //
    // Thus we have that we only need to round ties to even when
    // we have that q ∈ [−4,23](in the 64-bit case) or q∈[−17,10]
    // (in the 32-bit case). In both cases,the power of five(5^|q|)
    // fits in a 64-bit word.
    const MIN_EXPONENT_ROUND_TO_EVEN: i32;
    const MAX_EXPONENT_ROUND_TO_EVEN: i32;
```

This ensures maintainability of the code base.

**Improvements for Disguised Fast-Path Cases**

The fast path in float parsing algorithms attempts to use native, machine floats to represent both the significant digits and the exponent, which is only possible if both can be exactly represented without rounding. In practice, this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22, 22]` (for an f64). This is similar to the existing dec2flt implementation.

However, disguised fast-path cases exist, where there are few significant digits and an exponent above the valid range, such as `1.23e25`. In this case, powers-of-10 may be shifted from the exponent to the significant digits, discussed at length in https://github.com/rust-lang/rust/issues/85198.

**Digit Parsing Improvements**

Typically, integers are parsed from string 1-at-a-time, requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements, and is implemented for both big and little-endian systems.

**Unsafe Changes**

Relative to fast-float-rust, this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this, which is deceptively marked as safe for unsafe functionality.

```rust
impl AsciiStr {
    #[inline]
    pub fn step_by(&mut self, n: usize) -> &mut Self {
        unsafe { self.ptr = self.ptr.add(n) };
        self
    }
}

...

#[inline]
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    // the first character is 'e'/'E' and scientific mode is enabled
    let start = *s;
    s.step();
    ...
}
```

The new code clearly documents safety concerns, and does not mark unsafe functionality as safe, leading to better safety guarantees.

```rust
impl AsciiStr {
    /// Advance the view by n, advancing it in-place to (n..).
    pub unsafe fn step_by(&mut self, n: usize) -> &mut Self {
        // SAFETY: same as step_by, safe as long n is less than the buffer length
        self.ptr = unsafe { self.ptr.add(n) };
        self
    }
}

...

/// Parse the scientific notation component of a float.
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    let start = *s;
    // SAFETY: the first character is 'e'/'E' and scientific mode is enabled
    unsafe {
        s.step();
    }
    ...
}
```

This allows us to trivially demonstrate the new implementation of dec2flt is safe.

**Inline Annotations Have Been Removed**

In the previous implementation of dec2flt, inline annotations exist practically nowhere in the entire module. Therefore, these annotations have been removed, which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157).

**Fixed Correctness Tests**

Numerous compile errors in `src/etc/test-float-parse` were present, due to deprecation of `time.clock()`, as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse), and any errors in `runtests.py` have been patched.

**Undefined Behavior**

An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored, to ensure that the behavior is well-defined. The original code is as follows:

```rust
    #[inline]
    pub fn check_len(&self, n: usize) -> bool {
        unsafe { self.ptr.add(n) <= self.end }
    }
```

And the new implementation is as follows:

```rust
    /// Check if the slice at least `n` length.
    fn check_len(&self, n: usize) -> bool {
        n <= self.as_ref().len()
    }
```

Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29).

**Inferring Binary Exponents**

Rather than explicitly store binary exponents, this new implementation infers them from the decimal exponent, reducing the amount of static storage required. This removes the requirement to store [611 i16s](868c702d0c/library/core/src/num/dec2flt/table.rs (L8)).

# Code Size

The code size, for all optimizations, does not considerably change relative to before for stripped builds, however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu.

**new**

Using rustc version 1.55.0-dev.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|400k|300K
1|396k|292K
2|392k|292K
3|392k|296K
s|396k|292K
z|396k|292K

**old**

Using rustc version 1.53.0-nightly.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|3.2M|304K
1|3.2M|292K
2|3.1M|284K
3|3.1M|284K
s|3.1M|284K
z|3.1M|284K

# Correctness

The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests, along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham  [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore, it is unlikely that this algorithm will incorrectly round parsed floats.

# Issues Addressed

This will fix and close the following issues:

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 12:56:22 +00:00
Alex Huszagh
8752b40369 Changed dec2flt to use the Eisel-Lemire algorithm.
Implementation is based off fast-float-rust, with a few notable changes.

- Some unsafe methods have been removed.
- Safe methods with inherently unsafe functionality have been removed.
- All unsafe functionality is documented and provably safe.
- Extensive documentation has been added for simpler maintenance.
- Inline annotations on internal routines has been removed.
- Fixed Python errors in src/etc/test-float-parse/runtests.py.
- Updated test-float-parse to be a library, to avoid missing rand dependency.
- Added regression tests for #31109 and #31407 in core tests.
- Added regression tests for #31109 and #31407 in ui tests.
- Use the existing slice primitive to simplify shared dec2flt methods
- Remove Miri ignores from dec2flt, due to faster parsing times.

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 00:30:34 -05:00
The8472
8dd903cc77 implement ConstSizeIntoIterator for &[T;N] in addition to [T;N]
Due to #20400 the corresponding TrustedLen impls need a helper trait
instead of directly adding `Item = &[T;N]` bounds.
Since TrustedLen is a public trait this in turn means
the helper trait needs to be public. Since it's just a workaround
for a compiler deficit it's marked hidden, unstable and unsafe.
2021-07-16 20:38:42 +02:00
inquisitivecrystal
7fc4fc747c Stabilize [T; N]::map() 2021-07-15 16:27:08 -07:00
The8472
bd1c39dc6c implement TrustedLen for Flatten/FlatMap if the U: IntoIterator == [T; N]
This only works if arrays are passed directly instead of array iterators
because we need to be sure that they have not been advanced before
Flatten does its size calculation.
2021-07-15 22:59:30 +02:00
Chayim Refael Friedman
f10da9f50a Allow leading pipe in matches!() patterns.
This is allowed in `match` statement, and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.
2021-07-15 22:05:45 +03:00
Trevor Spiteri
b0f98c60a6 test integer log10 values close to all powers of 10 2021-07-07 14:07:32 +02:00