OpenBSD: Add polyImpl implementation for x86
Signed-off-by: Iain Buclaw <ibuclaw@users.noreply.github.com>
Merged-on-behalf-of: Martin Kinkelin <kinke@users.noreply.github.com>
Before this PR if RDRAND was working the chance of unpredictableSeed
returning -1 was 2^^-64 instead of the expected 2^^-32. Now the chance
is 2^^-32 - 2^^-64 + 2^^-96.
`spawn[Linked]` required the passed callable to return `void`. This is
unecessarily strict because both `void` and `noreturn` imply that no
actual value will be returned by the callable.
`noreturn[]` does not contain characters and hence is not subject to
autodecoding. The previous behaviour caused the range primitives (`put`,
...) to call into autodecoding related functions which couldn't handle
`noreturn[]`.
That error caused `isInputRange!(noreturn[])` to yield false.
The previous check assumed that non-`void` return implies a returned
value - which obviously does not apply for `noreturn`.
Further code then assumed that `void` handlers should throw an exception
and hence threw an error when it didn't throw.
...when instantiated with `noreturn`.
DMD is able to determine that a lazy `noreturn` expression will interrupt
the normal control flow (throw / halt / ...) s.t. it never reaches the
`return`.
If you pass it a range of class-based ranges, the initialization to
`typeof(_current).init` will be `null`. Calling the `save` method
on `null` will naturally be a memory violation. This generic check
will handle null without harming any other type since save of any
init value will be another init value.
Previously, if this call to 'open' failed, it would result in a spurious
test failure. Now, it instead causes the test to be skipped.
Possibly related to https://issues.dlang.org/show_bug.cgi?id=22350
The range algorithms moveFront, moveBack, and moveAt do not accept all
valid input ranges, bidirectional ranges, and random-access ranges,
respectively. Their inclusion as methods of the InputRange,
BidirectionalRange, and RandomAccessFinite interfaces previously caused
InputRangeObject, which implements those interfaces, to fail to compile
when instantiated with certain valid input, bidirectional, and
random-access ranges.
These methods should not have been included in their respective
interfaces to begin with, but removing them now would break existing
code. Instead, as a workaround, InputRangeObject now implements these
methods by throwing an exception if the wrapped range does not support
them.
This is another attempt to re-use the code in `Payload.reserve` --
similar to https://github.com/dlang/phobos/pull/8143 (commit 0b7bf8dc):
"std.container.Array: Simplify implementation of length (by calling reserve).".
Additionally, `Array`'s variadic constructor is now safer:
If `emplace`-ing an element fails, successfully `emplace`-d elements are now destroyed.
Example:
```
auto a = Array!S (S(0), S(1), S(2), S(3));
// If emplace-ing a[2] (as a copy of S(2)) fails:
// - pre-existing behaviour: a[1] and a[0] were not destroyed (bad);
// - new behaviour: a[1] and a[0] are destroyed (good).
```
A corresponding `unittest` has been added (`S.s_nDestroyed == S.s_nConstructed`):
When such a failure (`Exception`) is caught, there should be no leaked objects.
Implementation:
Previously:
- the `Payload` `length` used to be increased only once,
after having successfully `emplace`-d all elements,
thus incorrectly tracking the number of `emplace`-d elements during the loop
(but correctly tracking it after the loop -- iff the entire loop succeeded).
Now:
- the `Payload` `length` is incremented multiple times,
at each step i.e. after having successfully `emplace`-d each element,
thus correctly tracking the number of `emplace`-d elements during the loop.
Note:
When the constructor fails, the corresponding destructor is not run.
But the destructors for successfully constructed sub-objects are run;
in this case, the destructor for the `_data` sub-object is run --
and it is this destructor which destroys the successfully emplaced elements
(iff they have been correctly tracked).
One of the `unittest`'s has been modified to also check that
a `File` object managed via `RefCounted!File` handles is deleted
when its last handle is destroyed;
