* Use only fixed-width uints in the C itoa functions

The existing logic for decimal encoding of signed ints was a bit
more complicated than necessary in its handling for negative numbers,
mostly because of negation overflowing for INT_MIN.

But the absolute value of the smallest signed Int16 does fit into
an unsigned Word16 without overflowing, allowing some simplification.

Additionally, on hardware with slow integer division instructions,
fast division-by-known-divisor is typically faster for unsigned types,
so this change may lead to a slight speed-up on such platforms.

(We could almost certainly produce slightly better code still for
these platforms by hand, for example by exploiting the fact that
after the first division the numbers are small enough that a quotient
by ten can be extracted with a single mulhi and no shift.)

* Remove a dead branch in `integerDec`

If the absolute value of the input is small enough to enter this
branch, then it fits in an Int and takes the very first branch instead.

* Update changelog for bytestring-0.12.2.0

* Add invisible changelog entries for the latest backports

---------

Co-authored-by: Matthew Craven <clyring@gmail.com>

* Another attempt to fix NetBSD CI job

* Fix aarch64 job

* Bump uraimo/run-on-arch-action to 2.8.2

* Switch FreeBSD job to use ghcup

Some combinations of Apple toolchains and GHC versions will
provide headers that anger -Werror=undef.  See discussion
at that #665.

* Clarify documentation of 'customStrategy' based on #690

* Remove outdated comments on AllocationStrategy

(These were not visible in the Haddock output anyway.)

* Don't build tests with threaded runtime on WASM

* Skip lifting tests on WASM

* Tests: improve reporting of mismatches for IO tests

* Add WASM CI job

* CI: upgrade incantations for emualted tests

`toLazyByteString :: Builder -> LazyByteString` had a race condition that could
generate wrong results if two threads concurrently evaluated the result.  This
bug was introduced in #581 (5c4d2367) and first
present in release 0.11.5.0 (as 0c030bb6).

Due to the use of `unsafeDupablePerformIO` for performance, it is critical that
any IO actions executed when running a `Builder` can be interrupted or executed
multiple times.  In principle, filling a buffer is safe provided the buffer is
used only once and the same bytes are written each time. However, `wrapChunk` in
`buildStepToCIOS` would re-use a buffer in the trimming case after copying its
contents to produce a new trimmed chunk. This is safe when run in a single
thread, but if two threads simultaneously execute the code, one of them may
still be copying the contents while the other starts overwriting the buffer.

This patch fixes `wrapChunk` to unconditionally allocate a new buffer after
trimming, rather than re-using the old buffer. This will presumably come at a
slight performance cost for builders inserting many trimmed chunks.

* use vaulted centos packages

* removed centos 7 from ci

* Fix several bugs around the 'byteString' family of Builders

* Add Note [byteStringCopyStep and wrappedBytesCopyStep]

This makes explicit the reasoning for in what sense
"ensur[ing] that the common case is not recursive" is expected to
possibly "yield[] better code."

This is useless at best, and a common source of confusion.

https://github.com/haskell/cabal/pull/10145
https://github.com/sol/hpack/issues/355

Along the way:

 * Obseleted CPP and compatibility workarounds were removed
 * Most remaining CPP conditions are moved into
   bytestring-cpp-macros.h and given specific feature names
 * Most imports from ghc-prim are replaced with equivalent
   imports from base
 * Data.ByteString.Builder.RealFloat.Internal is left untouched,
   to avoid unnecessary conflicts

...with the hope of un-breaking CI

* Improve benchmarks for small Builders

   * Do not measure the overhead of allocating destination chunks
   * Add several more benchmarks for P.cstring and P.cstringUtf8

* More benchmark fiddling

* Update "since" markers for new NFData instances

* Bump actions/checkout to v4 in CI

* Keep old actions/checkout versions in containerized jobs

* Use default-extensions to tidy up a bit

* Fix ghc invocation in emulated CI jobs

* Use Haskell2010 in emulated jobs, too

* Make D.B.Lazy.zipWith properly lazy

As a bonus, the new code is easier to read and doesn't trigger
a spurious incomplete-pattern-match warning.  (Or finding the
bug can be seen as a bonus for cleaning up that messy code.)

Fixes #667.

* Lazy.zipWith: evaluate the 'unsafeHead' calls eagerly

Looking at a test coverage report brought it to my attention.

* WIP: Prepare changelog for 0.12.1.0

* fiddle with CI

* Revert "fiddle with CI"

This reverts commit 3e220052bb1f98ea574f7a362b98bf96fdc01f7e.

* More changelog updates

* Mention `pure-haskell` flag in Changelog.md

* Add hidden entry for #660

All of these were standard C functions that GHC's JS backend
actually somewhat supports; their shims can be found in the
compiler source at "rts/js/mem.js".  But it seems simpler to
just get rid of all FFI uses with -fpure-haskell rather than
try to keep track of which functions GHC supports.

The pure Haskell implementation of memcmp runs about 6-7x as fast
as the simple one-byte-at-a-time implementation for long equal
buffers, which makes it...  about the same speed as the
pre-existing shim, even though the latter is also a one-byte-
at-a-time implementation!

Apparently GHC's JS backend is not yet able to produce efficient
code for tight loops like these yet; the biggest problem is that
it does not perform any loopification so each iteration must go
through a generic-call indirection.

Unfortunately that means that this patch probably makes 'strlen'
and 'memchr' much slower with the JS backend.

This ensures that the result of `fromShort` is properly
protected by a call to `mkDeferredByteString`.

See #653.  A complete audit has not been done,
but let's just fix the known bug anyway.

bytestring used to rely on C functions. This patch adds equivalent
functions implemented in Haskell. The main purpose is for the JavaScript
backend to fully support bytestring.

Pure Haskell implementation can be enabled explicitly with a cabal flag.
It's automatically enabled for the JavaScript platform.

Thanks to Matthew Craven for the thorough review and the many
suggestions.

Co-authored-by: Matthew Craven <clyring@gmail.com>

* Data.ByteString.Lazy.dropEnd: Use two-pointers technique

This can be seen as using the input itself as an implicit
queue; we formerly copied its chunks into an explicit queue.

By writing the key logic as a polymorphic `splitAtEndFold`,
it was easy to re-use it for `takeEnd`; the latter function
should now operate in constant stack space and can release
initial chunks of a very long input string sooner.

* Fix a very silly bug, and strengthen tests

...so that a plain 'cabal test' finds the bug almost every try
instead of finding it only every few dozen tries

* Actually work around the poison instance

(Some re-compilation check somewhere set a trap for me.)

This also replaces fromIntegral with intToIndexTy in a few places.

* Rewrite the poison instance using TypeError

* Rename "bsL" -> "toSplit" and "bsR" -> "toScan"

* Add basic benchmarks for lazy takeEnd/splitEnd

According to these benchmarks, the new implementation for takeEnd
is somewhat faster and the new implementation for dropEnd is roughly
3.5x to 4x as quick as its predecessor.

Since `stimes` was explicitly implemented in #611:
Closes #488. Closes #489.

...with the hope of un-breaking the FreeBSD job.

* Use primops for unaligned writes when possible

* Check MIN_VERSION_base instead of __GLASGOW_HASKELL__

It is poorly documented and dangerous with respect to alignment
and internal padding. It is exposed only via the semi-internal
module Data.ByteString.Builder.Prim.Internal, and has no users
on Hackage. (Since #587 we do not use it internally.)

Replace confusing occurrences of strict/lazy ByteString in
generated documentation with the corresponding type
synonyms.

The windows jobs were subtly broken by #613, which caused
the build products to live in bytestring-*/dist-newstyle
instead of dist-newstyle.  This didn't appear to break
immediately because we restored cached stuff in dist-newstyle
including stale executables.  It wasn't until a week of
inactivity caused our cache to expire that the breakage
became appropriately obvious.

I don't really understand what went wrong with the centos job;
I just borrowed the workaround from haskell/text#541.

* Add functionality for toConstr

* Other instances fixed

* Move test

* test passes

* Add gshow tests

* Typo

* Add explicit string test

* instance Data: implement gunfold and dataTypeOf

* instance Data: fix tests

* Fix emulated builds

* Restore derived instance Data ShortByteString

* Add instance Generic ShortByteString

* Review suggestions

---------

Co-authored-by: Colton Clemmer <coltonclemmerdev@gmail.com>

This seems to exist for no reason, and prevents case-of-known-
constructor from eliminating an indirection in downstream modules.

Remove redundant imports and the redefinition of (<>).