[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.
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.
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`).
This requires us to allocate a single entry vector we didn't use to
allocate. I doubt this makes a difference in practice, as this only
occurs for cache misses.
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.
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.
