TagTuple wass previously nested within matchImpl, meaning it gets
a different instantiation for each match call with different handlers.
This is not required, as the only template parameters it needs are
the SumTypes being used. In practice, we might even get away with
using the length, but the gain is likely to be marginal compared
to the gains from moving it out of matchImpl.
Another underlying motivation for this change is that it works around
a compiler bug triggered with complex code using const SumType
(the compiler complains that 'this' for 'invariant' is of the wrong type,
const vs non-const).
* preallocate oom error
fixes issue 23196.
unfortunately, while i believe it should be possible to make this function `@nogc nothrow` [since we are throwing an error, which cannot be recovered from], i wasn't able to figure out how to get enforce to realise it. advice would be greatly appreciated on this front.
* undo wording change
* Update stdio.d
use onOutOfMemoryError instead of custom implementation
* nogc nothrow
* style fix
* remove unneeded variable
* remove unused import
The CustomFloat should be converted to real before most operations, but
there is no support for convertions of real types with
quadruple-precision (e.g. real type on RISCV64 platform). As the
significand is stored using 112 bits, which cannot fit in a ulong type
(CustomFloat do not allow significand more than a ulong), we should only
use the highest 64 bits of significand (this may cause presicion loss
from real type, but is enough for what CustomFloat can support
at most). So add 48 padding bits by declaring a uint and a
ushort before the significand, and set align(1) in this case.
chore(utf): documentation of byUTF is wrong about thrown exceptions
Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
Merged-on-behalf-of: Dennis <dkorpel@users.noreply.github.com>
Previous change that moved std.checkedint out of experimental stage
didn't added the module to the list of modules on std module
`std/package.d`. This patch does that.
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
The template `canMatch` does not account for `ref`.
The template `valueTypes` stores all types of the member values and uses SumTypes's `get` function, which returns a `ref`.
However, ref does not persist and the type is not sent to `canMatch` as a `ref`.
Because of this, when matching, `canMatch` will fail as it will test for a copy, and returning a reference of that value results in escaping it.
Fix Issue 23101
Signed-off-by: João Lourenço <jlourenco5691@gmail.com>
Extend the fill, alignSize, align{2,4} methods of `std.outbuffer.OutBuffer` to specify value to write
when filling (up to an alignment).
For flash device images it is desirable to use 0xff as the fill value,
because 0xff is the value of the unprogrammed flash memory cell. Padding
with 0 requires to programm the flash cell from 0xff to 0x00, which
increases wear and tear on the flash memory device. Usually there is some
larger block at the end if the flash memory image, which must be padded
up to the size of the flash device (usuallay a power of two). Instead
of padding with 0x00 the PR allows to fill with 0xff instead.
There might also be other use-cases, where it might be reasonable to fill
the alignment gaps with some other value than 0x00, e.g. when debugging
and viewing output data in a hex editor. It is easier to spot gaps, when
the padded spaces contain a custom value like 0x55 or 0xaa.
A new fill method was added, which allows filling with a user-defined value
instead of the 0 as in the previous implementation.
