-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 #72221
Rollup of 6 pull requests #72221
Commits on Apr 8, 2020
-
Configuration menu - View commit details
-
Copy full SHA for b70e7fd - Browse repository at this point
Copy the full SHA b70e7fdView commit details -
Configuration menu - View commit details
-
Copy full SHA for 2fcfd23 - Browse repository at this point
Copy the full SHA 2fcfd23View commit details -
Adjust Step::forward_checked docs for large types
Co-Authored-By: Nadrieril Feneanar <nadrieril@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for f34322d - Browse repository at this point
Copy the full SHA f34322dView commit details
Commits on May 3, 2020
-
Use
LocalDefId
inDumpVisitor::nest_tables
This is a partial fix for rust-lang#71104
Configuration menu - View commit details
-
Copy full SHA for e5a1be8 - Browse repository at this point
Copy the full SHA e5a1be8View commit details
Commits on May 13, 2020
-
Fix the new capacity measurement in arenas.
For the given code paths, the amount of space used in the previous chunk is irrelevant. (This will almost never make a difference to behaviour, but it makes the code clearer.)
Configuration menu - View commit details
-
Copy full SHA for 9111d8b - Browse repository at this point
Copy the full SHA 9111d8bView commit details -
Be less aggressive with
DroplessArena
/TypedArena
growth.`DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB, the second is 8 KiB, and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. Although these don't contribute to RSS, they clog up the DHAT profiles. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It gives a slight speed-up to cycle counts in some cases.
Configuration menu - View commit details
-
Copy full SHA for 40d4868 - Browse repository at this point
Copy the full SHA 40d4868View commit details -
Forbid stage arguments to check
Users generally expect that check builds are fast, and that's only true in stage 0 (stages beyond that need us to build a compiler, which is slow).
Configuration menu - View commit details
-
Copy full SHA for 2b42a2b - Browse repository at this point
Copy the full SHA 2b42a2bView commit details -
Configuration menu - View commit details
-
Copy full SHA for cef616b - Browse repository at this point
Copy the full SHA cef616bView commit details -
Improve Step::forward/backward for optimization
The previous definition did not optimize down to a single add operation, but this version does appear to.
Configuration menu - View commit details
-
Copy full SHA for 90b1961 - Browse repository at this point
Copy the full SHA 90b1961View commit details
Commits on May 14, 2020
-
* In 'src/librustc_ast_passes/node_count.rs' * typo fix ('rought' -> 'rough') * In 'src/librustc_middle/middle/region.rs', * fixed broken link to 'rustc-dev-guide' * typo fix ('aluded' -> 'alluded') Thank you for reviewing this PR :)
Configuration menu - View commit details
-
Copy full SHA for c919a6e - Browse repository at this point
Copy the full SHA c919a6eView commit details -
Configuration menu - View commit details
-
Copy full SHA for d53068e - Browse repository at this point
Copy the full SHA d53068eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 00d42bb - Browse repository at this point
Copy the full SHA 00d42bbView commit details -
Rollup merge of rust-lang#69659 - CAD97:step-rework-take-3, r=Amanieu
Rework the std::iter::Step trait Previous attempts: rust-lang#43127 rust-lang#62886 rust-lang#68807 Tracking issue: rust-lang#42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this, `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations, and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite, or if `end` would never be reached). /// /// # Invariants /// /// For any `a`, `b`, and `n`: /// /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::forward(&a, n) == Some(b)` /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::backward(&a, n) == Some(a)` /// * `steps_between(&a, &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a, &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a, &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a, &b) == None` if `a > b` fn steps_between(start: &Self, end: &Self) -> Option<usize>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, m).and_then(|x| Step::forward_checked(x, n))` /// /// For any `a`, `n`, and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::forward_checked(&x, 1))` /// * Corollary: `Step::forward_checked(&a, 0) == Some(a)` fn forward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::forward(Step::forward(a, n), m) == Step::forward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_checked(a, n) == Some(Step::forward(a, n))` /// * `Step::forward(a, n) == (0..n).fold(a, |x, _| Step::forward(x, 1))` /// * Corollary: `Step::forward(a, 0) == a` /// * `Step::forward(a, n) >= a` /// * `Step::backward(Step::forward(a, n), n) == a` fn forward(start: Self, count: usize) -> Self { Step::forward_checked(start, count).expect("overflow in `Step::forward`") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a`, it is safe to call `Step::forward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&a, &b) == Some(n)`, /// it is safe to call `Step::forward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_unchecked(a, n)` is equivalent to `Step::forward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn forward_unchecked(start: Self, count: usize) -> Self { Step::forward(start, count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a, x))` /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == try { Step::backward_checked(a, n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::backward_checked(&x, 1))` /// * Corollary: `Step::backward_checked(&a, 0) == Some(a)` fn backward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::backward(Step::backward(a, n), m) == Step::backward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_checked(a, n) == Some(Step::backward(a, n))` /// * `Step::backward(a, n) == (0..n).fold(a, |x, _| Step::backward(x, 1))` /// * Corollary: `Step::backward(a, 0) == a` /// * `Step::backward(a, n) <= a` /// * `Step::forward(Step::backward(a, n), n) == a` fn backward(start: Self, count: usize) -> Self { Step::backward_checked(start, count).expect("overflow in `Step::backward`") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a`, it is safe to call `Step::backward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&b, &a) == Some(n)`, /// it is safe to call `Step::backward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_unchecked(a, n)` is equivalent to `Step::backward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn backward_unchecked(start: Self, count: usize) -> Self { Step::backward(start, count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start, n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a "step by one" method directly, this version of the trait only exposes "step by n". There are a few reasons for this: - `Range*`, the primary consumer of `Step`, assumes that the "step by n" operation is cheap. If a single step function is provided, it will be a lot more enticing to implement "step by n" as n repeated calls to "step by one". While this is not strictly incorrect, this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl, this can be easily added backwards-compatibly later. - The debug-wrapping "step by n" needs to exist for `RangeFrom` to be consistent between "step by n" and "step by one" operation. (Note: the behavior is not changed by this PR, but making the behavior consistent is made tenable by this PR.) Three "kinds" of step are provided: `_checked`, which returns an `Option` indicating attempted overflow; (unsuffixed), which provides "safe overflow" behavior (is allowed to panic, wrap, or saturate, depending on what is most convenient for a given type); and `_unchecked`, which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the "common sense" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).
Configuration menu - View commit details
-
Copy full SHA for ae00cbb - Browse repository at this point
Copy the full SHA ae00cbbView commit details -
Rollup merge of rust-lang#71809 - marmeladema:fix-issue-71104, r=eddyb
Use `LocalDefId` in `DumpVisitor::nest_tables` This is a partial fix for rust-lang#71104
Configuration menu - View commit details
-
Copy full SHA for a3ae361 - Browse repository at this point
Copy the full SHA a3ae361View commit details -
Rollup merge of rust-lang#71872 - nnethercote:less-aggressive-arena-g…
…rowth, r=oli-obk Be less aggressive with `DroplessArena`/`TypedArena` growth. `DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB, the second is 8 KiB, and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena`, too.
Configuration menu - View commit details
-
Copy full SHA for 1c7eda3 - Browse repository at this point
Copy the full SHA 1c7eda3View commit details -
Rollup merge of rust-lang#72172 - Mark-Simulacrum:check-no-stage, r=a…
…lexcrichton Forbid stage arguments to check Users generally expect that check builds are fast, and that's only true in stage 0 (stages beyond that need us to build a compiler, which is slow). Closes rust-lang#69337 r? @alexcrichton
Configuration menu - View commit details
-
Copy full SHA for dea22ed - Browse repository at this point
Copy the full SHA dea22edView commit details -
Rollup merge of rust-lang#72200 - spastorino:add-prioritize_on-to-tri…
…agebot, r=Mark-Simulacrum Add prioritize_on attribute to triagebot r? @Mark-Simulacrum
Configuration menu - View commit details
-
Copy full SHA for 8b008a9 - Browse repository at this point
Copy the full SHA 8b008a9View commit details -
Rollup merge of rust-lang#72214 - JOE1994:nitpicky, r=jonas-schievink
Minor fixes to comments * In 'src/librustc_ast_passes/node_count.rs' * typo fix ('rought' -> 'rough') * In 'src/librustc_middle/middle/region.rs', * fixed broken link to 'rustc-dev-guide' * typo fix ('aluded' -> 'alluded') Thank you for reviewing this PR :)
Configuration menu - View commit details
-
Copy full SHA for ee43dc7 - Browse repository at this point
Copy the full SHA ee43dc7View commit details