In 8d90d3f368 `BufStream`, the only
consumer of `InternalBufWriter`, was removed. As implied by the name,
this type is private, hence it is currently dead code.
The following PR updates libc version to latest commits for correctly support openbsd.
It corrects several points in rustc to be compatible with libc changes.
r? @alexcrichton
Put back alloca zeroing for issues #29092, #30018, #30530; inject zeroing for #30822.
----
Background context: `fn alloca_zeroed` was removed in PR #22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's.
----
I first fixed#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of #30530.
While making the regression test for the latter, I discovered #30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant.
I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action).
----
(*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value.
Fix#29092Fix#30018Fix#30530Fix#30822
This adds the ability to override the default OOM behavior by setting a handler function. This is used by libstd to print a message when running out of memory instead of crashing with an obscure "illegal hardware instruction" error (at least on Linux).
Fixes#14674
This commit migrates all of the methods on `num::wrapping::OverflowingOps` onto
inherent methods of the integer types. This also fills out some missing gaps in
the saturating and checked departments such as:
* `saturating_mul`
* `checked_{neg,rem,shl,shr}`
This is done in preparation for stabilization,
cc #27755
Fixes#30477, #30213.
The loop over reexports used to be a closure before #30043 but it's an iterator now so it should just continue instead of exiting the loop and skipping stuff.
r? @brson
This PR fixes an ICE due to an DiagnosticsBuilder not being canceld or emitted.
Ideally it would use `Handler::cancel`, but I did not manage to get a `&mut` reference to the diagnostics handler.
(Note that it might be a good idea to replace *all* calls of
`alloc_ty` with calls to `alloc_ty_init`, to encourage programmers to
consider the appropriate value for the `init` flag when creating
temporary values.)
includes bugfixes pointed out during review:
* Only `call_lifetime_start` for an alloca if the function entry does
not itself initialize it to "dropped."
* Remove `schedule_lifetime_end` after writing an *element* into a
borrowed slice. (As explained by [dotdash][irc], "the lifetime end
that is being removed was for an element in the slice, which is not
an alloca of its own and has no lifetime start of its own")
[irc]: https://botbot.me/mozilla/rust-internals/2016-01-13/?msg=57844504&page=3
It appears this was left out of RFC rust-lang/rfcs#528 because it might be useful to
also generalize the second argument in some way. That doesn't seem to
prevent generalizing the first argument now, however.
This is a [breaking-change] because it could cause type-inference to
fail where it previously succeeded.
Also update docs for a few other methods that still referred to `&str` instead of patterns.
Add tables of small powers of ten used in the fast path. The tables are redundant: We could also use the big, more accurate table and round the value to the correct type (in fact we did just that before this commit). However, the rounding is extra work and slows down the fast path.
Because only very small exponents enter the fast path, the table and thus the space overhead is negligible. Speed-wise, this is a clear win on a [benchmark] comparing the fast path to a naive, hand-optimized, inaccurate algorithm. Specifically, this change narrows the gap from a roughly 5x difference to a roughly 3.4x difference.
[benchmark]: https://gist.github.com/Veedrac/dbb0c07994bc7882098e
Michael Ellerman pointed out that the system call for getrandom()
on PowerPC Linux is incorrect. This bug was in the powerpc32 port,
and was carried over to the powerpc64 port too.
Add tables of small powers of ten used in the fast path. The tables are redundant: We could also use the big, more accurate table and round the value to the correct type (in fact we did just that before this commit). However, the rounding is extra work and slows down the fast path.
Because only very small exponents enter the fast path, the table and thus the space overhead is negligible. Speed-wise, this is a clear win on a [benchmark] comparing the fast path to a naive, hand-optimized, inaccurate algorithm. Specifically, this change narrows the gap from a roughly 5x difference to a roughly 3.4x difference.
[benchmark]: https://gist.github.com/Veedrac/dbb0c07994bc7882098e
