Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 6 pull requests #40825

Closed
wants to merge 15 commits into from
Closed

Rollup of 6 pull requests #40825

wants to merge 15 commits into from

Conversation

adamransom and others added 15 commits March 22, 2017 19:27
Simply move the test for `keywords::StaticLifetime` into the
`Lifetime` impl, to match how elision is checked.
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).
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.
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%
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.
…=GuillaumeGomez

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.
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 rust-lang#40661

r? @jseyfried
…-doc, r=steveklabnik

Basic documentation for inclusive range syntax

Done so that we can remove mention of this from the stable documentation ⚠️.
…cess-levels, r=eddyb

"on-demandify" privacy and access levels

r? @eddyb
cc @cramertj rust-lang#40746
…=alexcrichton

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.
…rntSushi

Fix typo in dec2flt/algorithm.rs
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@frewsxcv
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Mar 25, 2017

📌 Commit 9d435fe has been approved by frewsxcv

@frewsxcv frewsxcv closed this Mar 25, 2017
@frewsxcv frewsxcv deleted the rollup branch March 25, 2017 16:29
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants