Expose 2 functions from std.json. These functions take a slice of bytes
and forward them to a given writer as a JSON encoded string.
The use case I have for this is in a custom JsonStringWriter. This writer
takes data and automatically encodes it as JSON string characters and
forwards it to an underlying writer. I use this JsonStringWriter in
combination with std.fmt.format to go directly from a format string/arg
pair to JSON. This way I don't have to format my string into a separate
buffer first and encode it afterwards, which avoids the need to create
a temporary buffer to hold the unencoded but formatted string.
`/usr/local/include`, `/usr/local/lib` and `/Library/Frameworks`
have been deprecated since approximately macOS 11, and so to avoid
redundant and misinformed warning messages generated by the linker,
add those dirs only when natively targeting macOS 10.x.x or below.
update() calls mem.indexOfScalar() which uses `==` for comparing items,
which fails when the operator is not supported.
As PirorityQueue needs a comparing function anyway we can use `.eq` results
to identify matching objects.
closes#9918
architectures
The idea behind this is using the register capabilities in safe amounts,
there is still some consideration to be done.
+ Fixed compile error using std.Target.<arch>.featureSetHas
+ X86 MMX and "3DNOW" 64 bits register usage considered for vector size
+ Added ARM Neon recommened usage of 128 bits (The size of the register)
+ Added AARCH64 Neon and SVE for 128 bits. SVE could use in theory up to
2048 bits, but found only evidence of functional 512 bits on a super
computer, decided on using 128 bits as a safety
+ Added Altivec recommendation of using the 128 bits long register
+ Using MIPS msa 2x64bits capabilities, usage of 64 bits registers for MDMX
systems, need testing on how using bigger values affect performance
+ Using V extension on RISC-V, which is extendable via instructions, decided on 128 bits
as a value to not use all registers
+ in SPARC the 64 bits registers are used, a max of 32 registers
are to be used for configurable simd instructions, decided on using
the size of the register, need testing on performance hit on using a
bigger sized register vector size
When lowering a struct type to an LLVM struct type, keep track of
whether there are any underaligned fields. If so, then make it a packed
llvm struct. This works because we already insert manual padding bytes
regardless.
We could unconditionally use an LLVM packed struct; the reason we bother
checking for underaligned fields is that it is a conservative choice, in
case LLVM handles packed structs less optimally. A future improvement
could simplify this code by unconditionally using packed LLVM structs
and then make sure measure perf is unaffected.
closes#12190
We were accidentally returning a pointer to stack memory, because these
arguments were passed by value. It's just an accident that stage 1 was
passing these by reference, so things were alright until stage 3.
