- 28 6月, 2018 11 次提交
-
-
由 kennytm 提交于
Document that Layout::from_size_align does not allow align=0 This was already implied since zero is not a power of two, but maybe worth pointing out.
-
由 kennytm 提交于
Fix the error reference for LocalKey::try_with There's no such thing as `ThreadLocalError` and the method obviously returns `AccessError`, so adjusting (probably only outdated docs).
-
由 kennytm 提交于
Add a compiletest header for edition r? @nikomatsakis Are the `-Zunstable-options` options needed in these tests? It looks like they aren't. If not, I can remove them.
-
由 kennytm 提交于
Lower case some feature gate error messages
-
由 kennytm 提交于
Only do sanity check with debug assertions on r? @nnethercote I'm slighty confused. These changes address code that the `unused-warnings` benchmark doesn't go through, yet I see a 5% improvement to nightly on the `check` run, and no improvement on the other runs. Maybe this change allows unrelated code in the same function to be better optimized?
-
由 kennytm 提交于
Document round-off error in `.mod_euc()`-method, see issue #50179 Due to a round-off error the method `.mod_euc()` of both `f32` and `f64` can produce mathematical invalid outputs. If `self` in magnitude is much small than the modulus `rhs` and negative, `self + rhs` in the first branch cannot be represented in the given precision and results into `rhs`. In the mathematical strict sense, this breaks the definition. But given the limitation of floating point arithmetic it can be thought of the closest representable value to the true result, although it is not strictly in the domain `[0.0, rhs)` of the function. It is rather the left side asymptotical limit. It would be desirable that it produces the mathematical more sound approximation of `0.0`, the right side asymptotical limit. But this breaks the property, that `self == self.div_euc(rhs) * rhs + a.mod_euc(rhs)`. The discussion in issue #50179 did not find an satisfying conclusion to which property is deemed more important. But at least we can document the behaviour. Which this pull request does.
-
由 kennytm 提交于
Add str::split_ascii_whitespace. As mentioned in #48656. While `str::split_whitespace` now works in `libcore`, it still makes sense to offer this method, considering how it is still more performant in cases where only ASCII is necessary.
-
由 Clar Charr 提交于
-
由 bors 提交于
Don't use `ParamEnv::reveal_all()` if there is a real one available fixes #51841 r? @Zoxc
-
由 bors 提交于
[fuchsia] Update zx_cprng_draw to target semantics This change is the final step in improving the semantics of zx_cprng_draw. Now the syscall always generates the requested number of bytes. If the syscall would have failed to generate the requested number of bytes, the syscall either terminates the entire operating system or terminates the calling process, depending on whether the error is a result of the kernel misbehaving or the userspace program misbehaving.
-
由 Oliver Schneider 提交于
-
- 27 6月, 2018 20 次提交
-
-
由 Adam Barth 提交于
This change is the final step in improving the semantics of zx_cprng_draw. Now the syscall always generates the requested number of bytes. If the syscall would have failed to generate the requested number of bytes, the syscall either terminates the entire operating system or terminates the calling process, depending on whether the error is a result of the kernel misbehaving or the userspace program misbehaving.
-
由 bors 提交于
Make opaque::Encoder append-only and make it infallible
-
由 Simon Sapin 提交于
This was already implied since zero is not a power of two, but maybe worth pointing out.
-
由 bors 提交于
Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem) Implement a solution for the macro helper issue discussed in https://github.com/rust-lang/rust/issues/35896 as described in https://github.com/rust-lang/rust/issues/35896#issuecomment-395977901. Macros exported from libraries can be marked with `#[macro_export(local_inner_macros)]` and this annotation changes how nested macros in them are resolved. If we have a fn-like macro call `ident!(...)` and `ident` comes from a `macro_rules!` macro marked with `#[macro_export(local_inner_macros)]` then it's replaced with `$crate::ident!(...)` and resolved as such (`$crate` gets the same context as `ident`).
-
由 Vadim Petrochenkov 提交于
-
由 John Kåre Alsaker 提交于
-
由 bors 提交于
Stabilize to_bytes and from_bytes for integers. Fixes #49792
-
由 bors 提交于
Lowering cleanups [2/N] Double indirections are unnecessary
-
由 Thayne McCombs 提交于
Fixes #49792
-
由 Michal 'vorner' Vaner 提交于
-
由 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.
-
由 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.
-
由 mark 提交于
-
由 mark 提交于
-
由 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.)
-
由 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
-
由 Josef Reinhard Brandl 提交于
-
由 Josef Reinhard Brandl 提交于
-
由 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.
-
由 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.
-
- 26 6月, 2018 9 次提交
-
-
由 Oliver Schneider 提交于
-
由 Oliver Schneider 提交于
-
由 Josef Reinhard Brandl 提交于
-
由 Zack M. Davis 提交于
-
由 Zack M. Davis 提交于
Our implementation ends up changing the `PatKind::Range` variant in the AST to take a `Spanned<RangeEnd>` instead of just a `RangeEnd`, because the alternative would be to try to infer the span of the range operator from the spans of the start and end subexpressions, which is both hideous and nontrivial to get right (whereas getting the change to the AST right was a simple game of type tennis). This is concerning #51043.
-
由 Zack M. Davis 提交于
These were stabilized in March 2018's #47813, and are the Preferred Way to Do It going forward (q.v. #51043).
-
由 Josef Reinhard Brandl 提交于
-
由 Oliver Schneider 提交于
-
由 bors 提交于
Combine all builtin late lints
-