-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rollup of 6 pull requests #40825
Conversation
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
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. |
@bors r+ p=10 |
📌 Commit 9d435fe has been approved by |
io::BufRead
doc examples to better demonstrate behaviors. #40642, Add warning for use of lifetime parameter with 'static bound #40734, Basic documentation for inclusive range syntax #40740, "on-demandify" privacy and access levels #40771, Optimize insertion sort #40807, Fix typo in dec2flt/algorithm.rs #40820