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.
Add warning for use of lifetime parameter with 'static bound
Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.
However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.
Example output:
```
warning: unnecessary lifetime parameter `'a`
--> ../static-lifetime-bound.rs:3:10
|
3 | fn f<'a: 'static>(val: &'a i32) {
| ^^^^^^^^^^^
|
= help: you can use the `'static` lifetime directly, in place `'a`
```
Fixes#40661
r? @jseyfried
Rewrite `io::BufRead` doc examples to better demonstrate behaviors.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
Previously a `'static` lifetime bound would result in an `undeclared
lifetime` error when compiling, even though it could be considered
valid.
However, it is unnecessary to use it as a lifetime bound so we present
the user with a warning instead and suggest using the `'static` lifetime
directly, in place of the lifetime parameter.
Fix formatting in the docs for std::process::Command::envs()
An empty line between the *Basic usage:* text and the example is required to properly format the code. Without the empty line, the example is not formatted as code.
[Here](https://doc.rust-lang.org/std/process/struct.Command.html#method.envs) you can see the current (improper) formatting.
Simplify hash table drops
This replaces the `std::collections:#️⃣:table::RevMoveBuckets`
iterator with a simpler `while` loop. This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.
This should be functionally equivalent to the former code, but a little
easier to read. I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same. Maybe it will
still help if an element type has more complicated drop code.
Revert #39485, fixing type-inference regressions
This reverts PR #39485, which should fix the immediate regressions. Eventually I'd like to land https://github.com/rust-lang/rust/pull/40224 -- or some variant of it -- which revisits the question fo dead-code and inference.
r? @eddyb
cc @canndrew
Fix for #39596: sort Trait2 before Trait10.
This is a change discussed in #39596. Essentially, item names will be sorted as if they're (&str, u64) pairs instead of just `&str`, meaning that `"Apple" < "Banana"` and also `"Fruit10" > "Fruit2"`.
Sample sorting:
1. Apple
2. Banana
3. Fruit
4. Fruit0
5. Fruit00
6. Fruit1
7. Fruit01
8. Fruit2
9. Fruit02
10. Fruit20
11. Fruit100
12. Pear
Examples of generated documentation:
https://docs.charr.xyz/before-doc/test_sorting/https://docs.charr.xyz/after-doc/test_sorting/
Screenshots of generated documentation:
Before: http://imgur.com/Ktb10ti
After: http://imgur.com/CZJjqIN
update LLVM with fix for PR32379
Fixes#40593.
The "root" codegen bug fixed here is that, when generating ARM code, unpatched LLVM 3.9/3.9.1 miscompiles bit operations in rare circumstances - this can cause user code compiled via LLVM (through both `rustc` and `clang`) to subtly return incorrect results - for more details, see the test in this PR or in the LLVM rare report.
One effect of that LLVM bug is that `rustc` 1.17 (and possibly other versions) is miscompiled on ARM. The code generated by a miscompiled `rustc` lacks destructor calls in many circumstances.
Users who run an affected/miscompiled `rustc` - 1.17 or above - on an ARM build machine will be affected by the (fairly blatant) missing destructor bug, regardless of the target architecture (this includes the official `1.17.0-beta.1`, `1.17.0-beta.2`, and some official 1.17/1.18 nightlies).
Users who use an affected LLVM (that's any unpatched LLVM 3.9/3.9.1), whether through `rustc` (in any version that supports 3.9 - that's 1.12 or above) or through `clang`, who compile code to an ARM target architecture might be affected by the (fairly hard to hit) bit operation bug, regardless of the build machine.
Distributors and user who want to compile rustc using their own LLVM should apply the [patch](cdc303e5ed) to avoid miscompilations.
r? @alexcrichton
Beta-nominating because regression (rustc 1.16 is not blatantly miscompiled). This also picks a fix for the (MSVC-affecting) PR29151.
appveyor: Upgrade MinGW toolchains we use
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
Closes#40546
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
Closes#40546
travis: See if OSX generates crash dumps
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
The person who originally wrote the example forgot to include this attribute.
This caused Travis CI to fail on commit 9b0a4a4e97 (#40794), which just fixed
formatting in the description of std::process::Command::envs().
An empty line between the "Basic usage:" text and the example is required to
properly format the code. Without the empty line, the example is not formatted
as code.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
I realized that, even in the current system, such reads can't really do
any harm. Because they are not part of a task, they will occur no matter
what (only tasks can be skipped). If you leak the data you read into a
task, that is bad, but that is equally bad if you are in a task.
*Writes* to tracked state, on the other hand, should never occur except
from within a task (and the task then records what things you read to
compute it).
Once we complete the shift to on-demand, these properties will hold by
construction (because the on-demand struct enforces stateless tasks
where leaks are impossible -- except by having shared mutable state in
the tcx).
There's a suspicion that the OOM killer is killing sccache (maybe) so this adds
some logging to test out that assumption to see if anything dies and is logged
by `dmesg`
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
appveyor: Leverage auto-retry to upload to S3
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Closes#39074
Let's have this layer be towards the end as we're emprically changing sccache
more than we're changing the rest of the image, so this'll allow us to reuse as
much of the cached image as possible.
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Closes#39074
Change object safety violation message
Hello!
This is my first pull request to rust so hopefully all goes well. This PR should fix issue #40670. I changed the error message in object_safety.rs and the corresponding compile-fail test in object-safety-supertrait-mentions-Self.rs.
Once the changes were made, I ran ```python x.py test src/tools/tidy``` and ```python x.py test```. Tidy passed and the compile-fail tests passed, however the test suite failed on the tcp tests as my machine has IPv6 disabled. I'm not sure what to do in this case besides letting travis run the suite against my changes. Please let me know if there's anything I can do to help further.
Thanks!
Mandeep
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.
On-demandify associated item retrieval
Part of #40614.
I also started converting `adt_def`, but I decided to open a PR with just this bit first to make sure I'm going about this correctly.
r? @nikomatsakis
Add diagnostic for incorrect `pub (restriction)`
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Follow up to #40340, fix#40599, cc #32409.
Use the "official" cross compiler for NetBSD
The current NetBSD cross compiler is lacking, for example `std::thread` is not available (which causes problems for LLVM 4.0). This PR uses the official netbsd build system to compiler the cross compiler.
@alexcrichton: Can you please mirror `ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/source/sets/{src,gnusrc,sharesrc,syssrc}.tgz`. (Optionally you may want to use NetBSD versions 7.0.2 or 7.1, in that case you'll probably want to update the binary downloads used today as well).
I'll update the URL's afterwards (or feel free to use "allow edits from maintainers").
r? @alexcrichton
travis: Add timestamps to all build messages
When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.
[utility]: https://github.com/alexcrichton/stamp-rsCloses#40577
