| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Replace hoedown with pull in rustdoc
cc @rust-lang/docs
|
|
|
|
|
|
|
|
`other` is guaranteed to be less than `2 * len`.
|
|
|
|
libcore: fix compilation on 16bit target (MSP430).
Since PR #40601 has been merged, libcore no longer compiles on MSP430.
The reason is this code in `break_patterns`:
```rust
let mut random = len;
random ^= random << 13;
random ^= random >> 17;
random ^= random << 5;
random &= modulus - 1;
```
It assumes that `len` is at least a 32 bit integer.
As a workaround replace `break_patterns` with an empty function for 16bit targets.
cc @stjepang
cc @alexcrichton
|
|
FromStr implementation example
Referencing #29375. Added example implementation of FromStr trait to API Documentation
|
|
Link ParseBoolError to from_str method of bool
Referencing task in #29375. Sorry for not opening another branch on my fork for this. Was working on this early this morning and forgot to branch off master
|
|
Don't stutter in operator trait descriptions
Fixes first item on #29365.
r? @steveklabnik
|
|
Select 3 random points instead of just 1.
Also the code now compiles on 16bit architectures.
|
|
|
|
Fix typo in dec2flt/algorithm.rs
|
|
Optimize insertion sort
This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56%
slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69%
slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50%
slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%
```
The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.
|
|
|
|
|
|
|
|
|
|
|
|
This change slightly changes the main iteration loop so that LLVM can
optimize it more efficiently.
Benchmark:
name before ns/iter after ns/iter diff ns/iter diff %
slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56%
slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69%
slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50%
slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%
|
|
Fix doc error for ExactSizeIterator
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
|
|
Various fixes to wording consistency in the docs
A bunch of random fixes, added punctuation, plurals, backticks, and so on...
r? @steveklabnik
|
|
str: Make docs consistently punctuated
Every so slightly pointless one character PR, but this was driving me nuts while reading the docs a moment ago (all the [other public structs](https://doc.rust-lang.org/std/str/index.html#structs) have descriptions that end in a full-stop).
|
|
Fix invalid linking in iter docs
r? @rust-lang/docs
|
|
|
|
What is this magic‽
|
|
|
|
|
|
|
|
|
|
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add missing urls in Option enum
r? @rust-lang/docs
|
|
Fix typo in `ptr` doc
`sizeof` should be `size_of`
|
|
Extract book into a submodule
Part of https://github.com/rust-lang/rust/issues/39588
We probably don't want to land this till after the beta branches on friday, but would still ❤️ a review from @alexcrichton , since I am a rustbuild noob.
This pr:
1. removes the book
2. adds it back in as a submodule
3. the submodule includes both the old book and the new book
4. it also includes an index page explaining the difference in editions
5. it also includes redirect pages for the old book URLs.
6. so we build all that stuff too.
r? @alexcrichton
|
|
Translate shims using MIR
This removes one large remaining part of old trans.
|
|
The unstable book, libstd, libcore, and liballoc all needed some
adjustment.
|
|
|
|
`sizeof` should be `size_of`
|
|
Rename TryFrom's associated type and implement str::parse using TryFrom.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".
See https://github.com/rust-lang/rust/issues/33417#issuecomment-269108968.
`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.
See https://github.com/rust-lang/rust/issues/33417#issuecomment-277175994
and https://github.com/rust-lang/rust/issues/33417#issuecomment-277253827.
Refs #33417.
|
|
Implemente overflowing_sh* with new unchecked_sh* intrinsics
Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations.
Fixes #40508.
cc @nagisa, @alexcrichton
Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.
|
