1. 27 6月, 2018 13 次提交
    • M
    • M
    • B
      Auto merge of #51835 - tmccombs:stable-int-to-from-bytes, r=joshtriplett · c2082432
      bors 提交于
      Stabilize to_bytes and from_bytes for integers.
      
      Fixes #49792
      c2082432
    • B
      Auto merge of #51815 - oli-obk:lowering_cleanups2, r=nikomatsakis · 971f7d34
      bors 提交于
      Lowering cleanups [2/N]
      
      Double indirections are unnecessary
      971f7d34
    • T
      Stabilize to_bytes and from_bytes for integers. · c8f9b84b
      Thayne McCombs 提交于
      Fixes #49792
      c8f9b84b
    • B
      Auto merge of #51598 - Pazzaz:master, r=sfackler · 612c2800
      bors 提交于
      Optimize sum of Durations by using custom function
      
      The current `impl Sum for Duration` uses `fold` to perform several `add`s (or really `checked_add`s) of durations. In doing so, it has to guarantee the number of nanoseconds is valid after every addition. If you squeese the current implementation into a single function it looks kind of like this:
      ````rust
      fn sum<I: Iterator<Item = Duration>>(iter: I) -> Duration {
          let mut sum = Duration::new(0, 0);
          for rhs in iter {
              if let Some(mut secs) = sum.secs.checked_add(rhs.secs) {
                  let mut nanos = sum.nanos + rhs.nanos;
                  if nanos >= NANOS_PER_SEC {
                      nanos -= NANOS_PER_SEC;
                      if let Some(new_secs) = secs.checked_add(1) {
                          secs = new_secs;
                      } else {
                          panic!("overflow when adding durations");
                      }
                  }
                  sum = Duration { secs, nanos }
              } else {
                  panic!("overflow when adding durations");
              }
          }
          sum
      }
      ````
      We only need to check if `nanos` is in the correct range when giving our final answer so we can have a more optimized version like so:
      ````rust
      fn sum<I: Iterator<Item = Duration>>(iter: I) -> Duration {
          let mut total_secs: u64 = 0;
          let mut total_nanos: u64 = 0;
      
          for entry in iter {
              total_secs = total_secs
                  .checked_add(entry.secs)
                  .expect("overflow in iter::sum over durations");
              total_nanos = match total_nanos.checked_add(entry.nanos as u64) {
                  Some(n) => n,
                  None => {
                      total_secs = total_secs
                          .checked_add(total_nanos / NANOS_PER_SEC as u64)
                          .expect("overflow in iter::sum over durations");
                      (total_nanos % NANOS_PER_SEC as u64) + entry.nanos as u64
                  }
              };
          }
          total_secs = total_secs
              .checked_add(total_nanos / NANOS_PER_SEC as u64)
              .expect("overflow in iter::sum over durations");
          total_nanos = total_nanos % NANOS_PER_SEC as u64;
          Duration {
              secs: total_secs,
              nanos: total_nanos as u32,
          }
      }
      ````
      We now only convert `total_nanos` to `total_secs` (1) if `total_nanos` overflows and (2) at the end of the function when we have to output a valid `Duration`. This gave a 5-22% performance improvement when I benchmarked it, depending on how big the `nano` value of the `Duration`s in `iter` were.
      612c2800
    • B
      Auto merge of #51773 - oli-obk:cleanup_impl_trait, r=nikomatsakis · d6e2239a
      bors 提交于
      Don't inspect the generated existential type items
      
      r? @nikomatsakis
      
      My debugging led me to the `hir::ItemExistential(..)` checks, which are entirely unnecessary because we never use the items directly. The issue was that items were iterated over in a random order (due to hashmaps), so if you checked the `ItemExistential` before the function that has the actual return `impl Trait`, you'd run into those ICEs you encountered.
      d6e2239a
    • B
      Auto merge of #51149 - zackmdavis:․․․_to_․․=, r=nikomatsakis · 0cf0691e
      bors 提交于
      lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase
      
      We probably need an RFC to actually deprecate the `...` syntax, but here's a candidate implementation for the lint considered in #51043. (My local build is super flaky, but hopefully I got all of the test revisions.)
      0cf0691e
    • B
      Auto merge of #51814 - MajorBreakfast:local-task-obj, r=cramertj · 84804c38
      bors 提交于
      Add `LocalTaskObj` to `core::task`
      
      - Splits `libcore/task.rs` into submodules
      - Adds `LocalTaskObj` and `SpawnLocalObjError` (-> [Commit for this](https://github.com/rust-lang/rust/commit/433e6b31a75eea5ce45493acc63eae462d740338))
      
      Note: To make reviewing easy, both actions have their own commit
      
      r? @cramertj
      84804c38
    • J
      Move spawn errors into executor.rs · b39ea1d1
      Josef Reinhard Brandl 提交于
      b39ea1d1
    • J
    • B
      Auto merge of #51756 - nielx:fix/librustdoc, r=GuillaumeGomez · 9cc3d44b
      bors 提交于
      Haiku: set stack size to 16 MB on Haiku, use 32 MB on other platforms
      
      The maximum stack size on Haiku is set to 16 MB (see [the Haiku source](https://git.haiku-os.org/haiku/tree/headers/private/system/thread_defs.h#n17)). With this change rustdoc will also work on Haiku.
      9cc3d44b
    • B
      Auto merge of #51725 - Mark-Simulacrum:no-llvm, r=kennytm · 7008a953
      bors 提交于
      Do not build LLVM tools for any of the tools
      
      None of the tools in the list should need LLVM tools themselves as far as I can
      tell; if this is incorrect, we can re-enable the tool building later.
      
      The primary reason for doing this is that rust-central-station uses the
      BuildManifest tool and building LLVM there is not cached: it takes ~1.5
      hours on the 2 core machine. This commit should make nightlies and
      stable releases much faster.
      
      Followup to https://github.com/rust-lang/rust/pull/51459, r? @kennytm
      
      I'm mostly relying on CI to test this so probably don't roll it up; I'm not sure how to (and not particularly inclined to) wait for multiple hours to test this locally. I imagine that the failures should be fairly obvious when/if encountered.
      7008a953
  2. 26 6月, 2018 27 次提交