Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
The assume intrinsic has a strong, negative impact on compile times, so
we're currently only using it in places where LLVM can simplify it to
nonnull metadata on a load intruction. Unfortunately a recent change
that fixed invalid assume calls introduce new assume calls for which
this simplification can not happen, leading to a massive regression in
compile times in certain cases.
Moving the assumptions from the middle of the function to the beginning
allows the simplification to happen again, bringing compile times back
to their old levels.
Fixes#25393
core::slice was originally written to tolerate overflow (notably, with
slices of zero-sized elements), but it was never updated to use wrapping
arithmetic when overflow traps were added.
Also correctly handle the case of calling .nth() on an Iter with a
zero-sized element type. The iterator was assuming that the pointer
value of the returned reference was meaningful, but that's not true for
zero-sized elements.
Fixes#25016.
core::slice::Iter.ptr can be null when iterating a slice of zero-sized
elements, but the pointer value used for the slice itself cannot. Handle
this case by always returning a dummy pointer for slices of zero-sized
elements.
Several Minor API / Reference Documentation Fixes
- Fix a few small errors in the reference.
- Fix paper cuts in the API docs.
Fixes#24882Fixes#25233Fixes#25250
core::slice was originally written to tolerate overflow (notably, with
slices of zero-sized elements), but it was never updated to use wrapping
arithmetic when overflow traps were added.
Also correctly handle the case of calling .nth() on an Iter with a
zero-sized element type. The iterator was assuming that the pointer
value of the returned reference was meaningful, but that's not true for
zero-sized elements.
Fixes#25016.
I was profiling my code again and this time AsRef<str> for String
was eating up a considerable chunk of my runtime; adding the inline
annotation made the program run almost twice as fast!
While I was at it I also added the annotation to other implementations
of AsRef as well as AsMut.
This is a direct port of my prior work on the float formatting. The detailed description is available [here](https://github.com/lifthrasiir/rust-strconv#flt2dec). In brief,
* This adds a new hidden module `core::num::flt2dec` for testing from `libcoretest`. Why is it in `core::num` instead of `core::fmt`? Because I envision that the table used by `flt2dec` is directly applicable to `dec2flt` (cf. #24557) as well, which exceeds the realm of "formatting".
* This contains both Dragon4 algorithm (exact, complete but slow) and Grisu3 algorithm (exact, fast but incomplete).
* The code is accompanied with a large amount of self-tests and some exhaustive tests. In particular, `libcoretest` gets a new dependency on `librand`. For the external interface it relies on the existing test suite.
* It is known that, in the best case, the entire formatting code has about 30 KBs of binary overhead (judged from strconv experiments). Not too bad but there might be a potential room for improvements.
This is rather large code. I did my best to comment and annotate the code, but you have been warned.
For the maximal availability the original code was licensed in CC0, but I've also dual-licensed it in MIT/Apache as well so there should be no licensing concern.
This is [breaking-change] as it changes the float output slightly (and it also affects the casing of `inf` and `nan`). I hope this is not a big deal though :)
Fixes#7030, #18038 and #24556. Also related to #6220 and #20870.
## Known Issues
- [x] I've yet to finish `make check-stage1`. It does pass main test suites including `run-pass` but there might be some unknown edges on the doctests.
- [ ] Figure out how this PR affects rustc.
- [ ] Determine which internal routine is mapped to the formatting specifier. Depending on the decision, some internal routine can be safely removed (for instance, currently `to_shortest_str` is unused).
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
This was causing function calls to be emitted for bitwise complements, even with optimizations on.
Steps to reproduce:
```
$ cat wrapping.rs
fn main() {
let a = std::num::Wrapping(std::env::args().len() as u32);
let b = !a;
println!("{}", b.0);
}
$ rustc -O wrapping.rs --emit=asm,link
$ grep Not wrapping.s
callq _ZN3num8wrapping23Wrapping$LT$u32$GT$.Not3not20hba4b266232e02b1dHkbE
```
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
Guard against overflow in `codemap::span_to_lines`.
(Revised/expanded version of PR #24976)
Make `span_to_lines` to return a `Result`.
In `diagnostic`, catch `Err` from `span_to_lines` and print `"(unprintable span)"` instead.
----
There a number of recent issues that report the bug here. See e.g. #24761 and #24954.
This change *might* fix them. However, that is *not* its main goal. The main goals are:
1. Make it possible for callers to recover from an error here, and
2. Insert a more conservative check, in that we are also checking that the files match up.
----
As a drive-by, fix#24997 , which was causing my attempts to `make check-stage1` on an `--enable-debug` build to fail.
Explicitely spell out behaviour on overflow for `usize`-returning iterator
functions.
Mention that panics are guaranteed if debug assertions are active, otherwise a
wrong result might be returned.
For the shortest mode the IEEE 754 decoder already provides
an exact rounding range accounting for banker's rounding,
but it was not the case for the exact mode. This commit alters
the exact mode algorithm for Dragon so that any number ending at
`...x5000...` with even `x` and infinite zeroes will round to
`...x` instead of `...(x+1)` as it was. Grisu is not affected
by this change because this halfway case always results in
the failure for Grisu.
The bug involves the incorrect logic for `core::num::flt2dec::decoder`.
This makes some numbers in the form of 2^n missing one final digits,
which breaks the bijectivity criterion. The regression tests have been
added, and f32 exhaustive test is rerun to get the updated result.
This is a fork of the flt2dec portion of rust-strconv [1] with
a necessary relicensing (the original code was licensed CC0-1.0).
Each module is accompanied with large unit tests, integrated
in this commit as coretest::num::flt2dec. This module is added
in order to replace the existing core::fmt::float method.
The forked revision of rust-strconv is from 2015-04-20, with a commit ID
9adf6d3571c6764a6f240a740c823024f70dc1c7.
[1] https://github.com/lifthrasiir/rust-strconv/
Specifically, make count, nth, and last call the corresponding methods
on the underlying iterator where possible. This way, if the underlying
iterator has an optimized count, nth, or last implementations (e.g.
slice::Iter), these methods will propagate these optimizations.
Additionally, change Skip::next to take advantage of a potentially
optimized nth method on the underlying iterator.
