. "$BST_LIB"
# BST-TIMEOUT: 3600 # EIGHT python3 starts, and they are the whole cost.
#                   #
#                   # FOUR are taken directly here: a bare `import'; a second
#                   # import whose STDERR is the assertion (`import-quiet'); the
#                   # probe, which takes ONE start for eighty-six measurements;
#                   # and one run of the shipped simplejson.tool over a fixture,
#                   # which is a separate process by nature -- the point of the
#                   # case is that the CLI resolves its own import.
#                   #
#                   # The other FOUR are one call: `upstream-run' starts the
#                   # interpreter once to run the 146 tests the
#                   # python3-simplejson-tests sub-package ships, and THREE of
#                   # those tests (simplejson.tests.test_tool) spawn
#                   # `python3 -m simplejson.tool' as a subprocess of their own.
#                   # That is the most expensive single case in this file and
#                   # the reason the bound is 3600 rather than the 1200 a
#                   # pure-Python port of this size would take.
#                   #
#                   # 3600 is 450s per start, against the ~60s a python3 start
#                   # has measured at on this arm -- the same per-start margin
#                   # 99-python3-cbor2 carries at 2400 for five.
#                   #
#                   # NOTHING HERE IS QUADRATIC IN ANYTHING. Every fixture is a
#                   # few dozen bytes; the largest is the 100-byte tool fixture.
#                   # The one unbounded recursion simplejson can be made to
#                   # perform -- `check_circular=False' over a self-referential
#                   # list -- is DELIBERATELY NOT EXERCISED, here or in the
#                   # probe: see the probe's `circular_refused' comment.
#                   #
#                   # NOT MEASURED ON TARGET YET: this port's first on-target
#                   # run is the batch verify, and the measured elapsed replaces
#                   # this note in the test plan rather than in this comment,
#                   # which would cost an image build to keep the shipped suite
#                   # byte-identical.
#
# python3-simplejson 3.19.2 (meta-openembedded/meta-python
# recipes-devtools/python/python3-simplejson_3.19.2.bb, `inherit pypi
# setuptools3', PyPI sdist, no patches) on the wasm32-hwjs glibc image.
#
# ============================================================================
# WHAT THE PACKAGE DOES.
# ============================================================================
#
# simplejson is the JSON implementation the standard library's `json' module
# was DERIVED FROM, still maintained separately and still ahead of it. Everything
# `json' does it does, with the same call names, plus the four things it is
# actually installed for:
#
#   * DECIMAL ROUND-TRIPPING. `json' turns a Decimal into a float and loses the
#     value; simplejson carries the digits through both directions.
#   * DETERMINISTIC KEY ORDER, by key (`sort_keys') or by an arbitrary callable
#     over the (key, value) pair (`item_sort_key').
#   * ENCODING RULES FOR TYPES `json' REFUSES -- namedtuples as objects,
#     arbitrary iterables as arrays, an object naming its own encoding through
#     `for_json', pre-encoded text through RawJSON.
#   * THE JAVASCRIPT-CONSUMER KNOBS -- `bigint_as_string' for integers past a
#     double's mantissa, `ignore_nan' to rewrite NaN and Infinity as `null',
#     and JSONEncoderForHTML for output embedded in a <script> element.
#
# ============================================================================
# THE ONE THING THIS PORT DECIDED, AND WHY EVERY CASE BELOW DEPENDS ON IT.
# ============================================================================
#
# simplejson ships TWO implementations of the same codec: the pure-Python
# encoder/decoder/scanner, and `simplejson._speedups', a CPython extension.
# Each of the three modules that can use it picks at import time, inside a
# `try: from ._speedups import ... except ImportError:'.
#
# THIS IMAGE SHIPS THE PURE-PYTHON HALF AND NO EXTENSION AT ALL. A
# self-contained CPython extension links on this arm -- measured on
# python3-bitarray (BRINTOS-2032) and python3-crcmod (BRINTOS-2038), each
# producing a real wasm dylink.0 side module -- but it can never bind: this
# image's python3.12 exports 35 symbols, none of them Py*, with no
# libpython3.12.so shipped to bind against instead (BRINTOS-2046). So
# python3-simplejson_%.bbappend sets upstream's own DISABLE_SPEEDUPS=1 for
# class-target and the file is not built.
#
# `pkg-no-so', `no-c-ext' and the four `c-*' cases below are therefore not
# hygiene: they are the assertion that the bbappend still takes. A run where
# they went red would mean every behavioural case in this suite had silently
# changed which code it was measuring.
#
# ============================================================================
# THIS PORT RUNS THE UPSTREAM SUITE AS PACKAGED, WHICH NOTHING ELSE IN THIS
# ROUND CAN.
# ============================================================================
#
# The recipe declares `PACKAGES =+ "${PN}-tests"' and puts `simplejson/tests'
# and `tool.py' into python3-simplejson-tests, whose only dependency is
# python3-unittest. That is an ORDINARY sub-package and this image satisfies it.
# Everywhere else in this round the upstream tests arrive in a `-ptest' package
# that reaches python3-pytest and cannot be installed here, so those suites
# re-derive the tests by hand.
#
# So `upstream-*' below is the substance of the port: 146 upstream tests run
# in-process against the shipped module, with the ids of any that fail. The
# hand-written cases around it are NOT a duplicate of that -- they pin the
# behaviours that distinguish simplejson from `json', each against a literal, so
# that a red names the feature rather than a test id.
#
# `upstream-clean' ASSERTS AN EMPTY SET AND IS GATED ON THE RUN HAVING HAPPENED.
# An empty failure list is also what a run that never started produces, so
# `upstream-done' and `upstream-ran' are checked FIRST and the empty-set case is
# only meaningful behind them (BRINTOS-2081).
#
# ============================================================================
# WHERE THE EXPECTED VALUES CAME FROM.
# ============================================================================
#
# Every expectation in this file is the OUTPUT of a control run, not a reading
# of the source: simplejson 3.19.2, pure-Python, on CPython 3.12.13 -- the same
# version the target runs, taken from this build's own python3-native sysroot
# rather than from a distro python. The upstream suite on that control is
# 146 run, 0 failed, 0 errored, 8 skipped.
#
# ============================================================================
# THE THREE FINDINGS MOST LIKELY TO BE MISREAD AS PORT BUGS.
# ============================================================================
#
# `allow_nan' DEFAULTS THE OPPOSITE WAY FROM THE STANDARD LIBRARY. `json.dumps'
# has allow_nan=True and emits `NaN'/`Infinity' unasked; simplejson has
# allow_nan=False on BOTH dumps and loads and RAISES. `nan-default-refused' and
# `nan-decode-default' pin the refusals and `nan-allow-on' pins the spelling, so
# a reader who expected the `json' behaviour is corrected here rather than
# filing it.
#
# `use_decimal' DEFAULTS DIFFERENTLY IN THE TWO DIRECTIONS: True for `dumps',
# False for `loads'. A Decimal therefore survives encoding unasked and comes
# back a FLOAT unless the caller asks for it. `decimal-loads-type' and
# `decimal-loads-default-type' are that asymmetry, both arms.
#
# A DUPLICATE KEY IS NOT AN ERROR, under `strict' or otherwise -- the last value
# wins, as JSON itself leaves open, and `strict' is about CONTROL CHARACTERS
# rather than about any general pedantry. `duplicate-key*' and
# `strict-control-char' pin both halves, because a reader coming from a
# validating parser expects a refusal and would otherwise read the silence as a
# gap in this suite.
#
# ============================================================================
# WHAT IS DELIBERATELY NOT COVERED.
# ============================================================================
#
# `_toggle_speedups' CANNOT RUN THE CORPUS THROUGH BOTH IMPLEMENTATIONS HERE,
# because there is only one implementation. What is asserted instead is that the
# toggle is HARMLESS on a build with no extension -- it must leave the
# pure-Python callables bound and must not raise, because the shipped
# `simplejson.tests' harness calls it on every run. `toggle-*' is that.
#
# ============================================================================

P=python3-simplejson

# `suite-canary' is emitted FIRST and unconditionally. A suite that dies before
# its first result line is indistinguishable from one that was never scheduled,
# so this one line is what separates "ran and found nothing" from "did not run".
bst_ok $P/suite-canary

require python3 $P/python3-present

SITE=/usr/lib/python3.12/site-packages
PKG=$SITE/simplejson
DI=$SITE/simplejson-3.19.2.dist-info
PKGLIST=/var/lib/dpkg/info/python3-simplejson.list
TESTLIST=/var/lib/dpkg/info/python3-simplejson-tests.list
PROBE=$BST_DATA/python3-simplejson-probe.py
UPSTREAM=$BST_DATA/python3-simplejson-upstream.py
TOOLFIX=$BST_DATA/python3-simplejson-tool.json
tmp=${TMPDIR:-/tmp}
W=$tmp/bst-simplejson.$$
mkdir -p "$W" || { bst_notok $P/workdir "cannot create $W"; exit 0; }

# ---------------------------------------------------------------- packaging --
# WHERE THE PACKAGING SAYS THE MODULE LANDS. These run before any import, so a
# red here says the .deb is wrong rather than that the codec misbehaves.
check $P/site-packages-dir test -d "$SITE"
check $P/package-dir       test -d "$PKG"
check $P/package-init      test -s "$PKG/__init__.py"

# It is a PACKAGE, not a single module. A release that flattened it would still
# import and still pass every behavioural case, so the shape is asserted.
check $P/no-flat-module    test ! -f "$SITE/simplejson.py"

# The six modules the public names come out of. `__init__.py' does
# `from .decoder import JSONDecoder', so a truncated install fails at import
# rather than here -- naming them individually is what turns "the package is
# complete" into a measurement the packaging can be judged by.
for _m in compat decoder encoder errors ordered_dict raw_json scanner; do
  check $P/module-$_m test -s "$PKG/$_m.py"
done

# ---------------------------------------------------- THE EXTENSION IS ABSENT --
# THE ASSERTION THE WHOLE PORT TURNS ON. `_speedups.cpython-312.so' is what the
# stock recipe builds and what python3-simplejson_%.bbappend declines; it cannot
# bind this interpreter's C API (BRINTOS-2046) and would ship an artifact whose
# best outcome is being swallowed by three except-clauses. Both the file and the
# shape of the package list are asserted, because the second one catches a .so
# landing under any other name.
check $P/no-c-ext-so       test ! -e "$PKG/_speedups.cpython-312.so"
check $P/no-c-ext-any      sh -c "! ls $PKG/_speedups*.so >/dev/null 2>&1"

# The .c the extension would have been built from is NOT installed either -- it
# is a build input, and a wheel carrying it would mean the sdist had been
# packaged wholesale rather than built.
check $P/no-c-source       test ! -e "$PKG/_speedups.c"

# NO CONSOLE SCRIPT. Unlike python3-cbor2 this project declares no
# `[project.scripts]', so there is no /usr/bin entry point and `tool-*' below
# reaches the CLI through `python3 -m simplejson.tool' instead.
check $P/no-bin-script     test ! -e /usr/bin/simplejson

# --------------------------------------------------------- the dist-info ------
check     $P/dist-info-dir      test -d "$DI"
check     $P/dist-info-metadata test -f "$DI/METADATA"
check_out $P/dist-info-version  "Version: 3.19.2" cat "$DI/METADATA"
check_out $P/dist-info-name     "Name: simplejson" cat "$DI/METADATA"
check     $P/dist-info-wheel    test -f "$DI/WHEEL"

# Root-Is-Purelib: true IS THE BBAPPEND'S SIGNATURE IN THE METADATA. With the
# extension built this wheel is platlib and the tag is a platform tag; with it
# declined the wheel is pure and the tag is py3-none-any. So these two lines
# say, from the packaging side rather than from a file check, that the build
# produced a pure-Python distribution.
check_out $P/dist-info-purelib  "Root-Is-Purelib: true" cat "$DI/WHEEL"
check_out $P/dist-info-tag      "Tag: py3-none-any" cat "$DI/WHEEL"

# top_level.txt names ONLY `simplejson', and the wheel carries its licence.
check_eq  $P/dist-info-top-level "simplejson" "$(cat "$DI/top_level.txt" 2>/dev/null)"
check     $P/dist-info-record   test -s "$DI/RECORD"
check     $P/dist-info-licence  test -s "$DI/LICENSE.txt"

# ------------------------------------------------------------ the .deb list ---
cat "$PKGLIST" > "$W/pkgf" 2>/dev/null || : > "$W/pkgf"
check $P/pkg-list-present test -s "$W/pkgf"

# NO SHARED OBJECT ANYWHERE IN THE PACKAGE. The file check above names the one
# path the extension would take; this one catches it under any name.
check_eq $P/pkg-no-so "" \
  "$(grep -c '\.so$' "$W/pkgf" 2>/dev/null | grep -v '^0$')"

# THE TESTS ARE IN THEIR OWN PACKAGE AND NOT IN THIS ONE. `PACKAGES =+
# "${PN}-tests"' is what makes `upstream-*' possible at all, and it is also what
# keeps simplejson/tests out of the runtime package -- so both halves are
# asserted, on the two file lists rather than on one.
check_eq $P/pkg-runtime-has-no-tests "" \
  "$(grep -c '/simplejson/tests/' "$W/pkgf" 2>/dev/null | grep -v '^0$')"
# tool.py IS present on the filesystem -- the -tests package puts it there --
# so this is an assertion about the RUNTIME package's file list, not about the
# path. Getting that round the wrong way is the mistake the split invites.
check_eq $P/pkg-runtime-has-no-tool "" \
  "$(grep -c '/simplejson/tool\.py$' "$W/pkgf" 2>/dev/null | grep -v '^0$')"

# Everything the runtime package ships is Python or metadata. A file that is
# neither is a packaging change nobody described -- and it is the check that
# would catch the accelerator landing under a name `no-c-ext-any' does not
# anticipate.
_bad=""
while IFS= read -r _f; do
  case "$_f" in
    ''|/usr/lib/python3.12/site-packages) continue ;;
    */) continue ;;
  esac
  [ -d "$_f" ] && continue
  case "$_f" in
    *.py|*.pyc) ;;
    */METADATA|*/WHEEL|*/RECORD|*/INSTALLER|*/LICENSE.txt|*/top_level.txt) ;;
    *) _bad="$_bad $_f" ;;
  esac
done < "$W/pkgf"
check_eq $P/pkg-only-python "" "$_bad"
cat "$TESTLIST" > "$W/testf" 2>/dev/null || : > "$W/testf"
check $P/pkg-tests-list-present test -s "$W/testf"
check_out $P/pkg-tests-has-suite "/simplejson/tests/test_decode.py" cat "$W/testf"
check_out $P/pkg-tests-has-tool  "/simplejson/tool.py" cat "$W/testf"

# A PACKAGING QUIRK, RECORDED SO IT IS NOT REDISCOVERED AS A DEFECT. The
# recipe's FILES:${PN}-tests glob is `simplejson/tool.py*', which matches
# tool.py but NOT simplejson/__pycache__/tool.cpython-312.pyc -- so the compiled
# form of tool.py stays in the RUNTIME package while its source is in -tests.
# Nothing breaks: the interpreter recompiles from source when it finds a .pyc
# without one, and `tool-output' below proves it runs. It is upstream
# meta-openembedded's split, not this port's, and we file nothing against
# third-party public repositories.
check $P/pkg-runtime-has-tool-pyc test -e "$PKG/__pycache__/tool.cpython-312.pyc"

# ------------------------------------------------------------- dpkg status ----
sed -n '/^Package: python3-simplejson$/,/^$/p' /var/lib/dpkg/status > "$W/st" 2>/dev/null
check     $P/pkg-known     test -s "$W/st"
check_out $P/pkg-installed "Status: install ok installed" cat "$W/st"

# THE DEPENDENCY SET, AND EVERY ONE OF THEM IS A SUB-PACKAGE OF THE PORTED
# INTERPRETER. The recipe adds python3-io, python3-netserver and python3-numbers
# on top of python3-core: `io' for the StringIO the encoder writes into,
# `netserver' because simplejson/compat.py reaches email.utils, and `numbers'
# for the Decimal/Integral checks the use_decimal path makes. Nothing here needs
# a package from outside the interpreter, which is why this port has no DEPENDS
# at all.
grep '^Depends:' "$W/st" > "$W/dep" 2>/dev/null || : > "$W/dep"
check $P/pkg-depends-line test -s "$W/dep"
for _d in python3-core python3-io python3-netserver python3-numbers; do
  check_out $P/pkg-depends-$_d "$_d" cat "$W/dep"
done

sed -n '/^Package: python3-simplejson-tests$/,/^$/p' /var/lib/dpkg/status > "$W/stt" 2>/dev/null
check     $P/pkg-tests-known     test -s "$W/stt"
check_out $P/pkg-tests-installed "Status: install ok installed" cat "$W/stt"
check_out $P/pkg-tests-depends   "python3-unittest" cat "$W/stt"

# ----------------------------------------------------------------- import -----
check $P/import python3 -c 'import simplejson'

# AND IT MUST BE SILENT. `import simplejson' on a build that still shipped an
# unloadable _speedups.so could succeed and print -- the except-clauses swallow
# the ImportError, but nothing swallows a loader diagnostic on stderr. An empty
# stderr is therefore a statement about the extension as much as about the
# module.
check_eq $P/import-quiet "" \
  "$(python3 -c 'import simplejson' 2>&1 >/dev/null)"

# ------------------------------------------------------------------ probe -----
if [ ! -f "$PROBE" ]; then
  bst_notok $P/probe-present "probe missing at $PROBE"
else
  bst_ok $P/probe-present
fi

# 900s for the one start that does eighty-six measurements, none of them longer
# than a hundred bytes. On overrun bst_probe names the last line the probe
# printed, which names the case it stopped at.
bst_probe $P/probe-run "$W/probe" 900 python3 "$PROBE"

OUT="$W/probe"

# One `grep' per value, split on the FIRST `=' so a value containing one is
# safe. Every key the probe emits is [a-z0-9_]+.
pv() { grep "^$1=" "$OUT" 2>/dev/null | head -n 1 | cut -d= -f2-; }

# THE PROBE RAN TO THE END AND EMITTED EVERYTHING. Without these two, a probe
# that died half way would report every case after the death as a mismatch
# against an empty string, which reads as eighty behavioural failures instead of
# one truncated transcript.
check_eq $P/probe-complete "yes" "$(pv probe_done)"
check_eq $P/probe-count    "86"  "$(pv emitted_count)"

# ---------------------------------------------------------------- identity ---
# WHICH COPY ANSWERED, AND WHICH OF THE TWO IMPLEMENTATIONS IT IS.
check_eq $P/module-answered "$PKG/__init__.py" "$(pv module_file)"
check_eq $P/is-package "yes" "$(pv is_package)"
check_eq $P/dist-version "3.19.2" "$(pv version)"
check_eq $P/has-dumps "yes" "$(pv has_dumps)"

# THE FOUR NAMES THE ACCELERATOR WOULD HAVE BOUND, AND THEY ARE ALL None. This
# is the same assertion as `no-c-ext-so' made from inside the interpreter: the
# file check says the artifact is absent, these say the codec knows it.
check_eq $P/c-make-encoder "None" "$(pv c_make_encoder)"
check_eq $P/c-encode-basestring-ascii "None" "$(pv c_encode_basestring_ascii)"
check_eq $P/c-scanstring "None" "$(pv c_scanstring)"
check_eq $P/c-make-scanner "None" "$(pv c_make_scanner)"
check_eq $P/c-import-make-encoder "None" "$(pv import_c_make_encoder)"
check_eq $P/c-ext-import-fails "ModuleNotFoundError" "$(pv speedups_import)"

# AND THE PURE-PYTHON CALLABLES ARE THE ONES BOUND IN THEIR PLACE. A different
# statement from the four above: those say the extension is absent, these say
# the fallback was wired rather than the public name left unbound.
check_eq $P/py-scanstring-bound "yes" "$(pv scanstring_is_py)"
check_eq $P/py-make-scanner-bound "yes" "$(pv make_scanner_is_py)"
check_eq $P/py-encode-basestring-ascii-bound "yes" "$(pv encode_basestring_ascii_is_py)"

# ------------------------------------------------------- the toggle is safe ---
# `simplejson.tests' calls `_toggle_speedups' on every run, so a build with no
# extension must survive it. Asked to turn the accelerator ON, the toggle's own
# `or' arms fall back to the pure callables.
check_eq $P/toggle-on-is-py "yes" "$(pv toggle_on_is_py)"
check_eq $P/toggle-off-is-py "yes" "$(pv toggle_off_is_py)"
check_eq $P/toggle-roundtrip '{"a": [1, 2, 3]}' "$(pv toggle_roundtrip)"
check_eq $P/toggle-restored "yes" "$(pv toggle_restored)"

# ------------------------------------------------------------------ Decimal --
# THE HEADLINE DIFFERENCE FROM THE STANDARD LIBRARY. `json' turns a Decimal into
# a float and loses the value; simplejson writes its digits and reads them back.
# `decimal-float-lossy' is what makes `decimal-roundtrip' mean something: it
# measures that 1.1 has no exact binary form, so a float path would NOT have
# come back equal.
check_eq $P/decimal-dumps-default "1.1" "$(pv decimal_dumps_default)"
check_eq $P/decimal-dumps-off "TypeError: Object of type Decimal is not JSON serializable" "$(pv decimal_dumps_off)"
check_eq $P/decimal-loads-type "Decimal" "$(pv decimal_loads_type)"
check_eq $P/decimal-loads-default-type "float" "$(pv decimal_loads_default_type)"
check_eq $P/decimal-roundtrip "yes" "$(pv decimal_roundtrip)"
check_eq $P/decimal-float-lossy "yes" "$(pv decimal_float_lossy)"
check_eq $P/decimal-big "1E+400" "$(pv decimal_big)"
check_eq $P/decimal-big-roundtrip "yes" "$(pv decimal_big_roundtrip)"
check_eq $P/decimal-nan "NaN" "$(pv decimal_nan)"
check_eq $P/decimal-in-container '{"a": 0.10}' "$(pv decimal_in_container)"

# ---------------------------------------------------------------- key order --
# TWO DIFFERENT ORDERINGS, AND THEY ARE NOT THE SAME KNOB. `sort_keys' sorts by
# the key; `item_sort_key' takes a callable over the (key, value) PAIR, so it
# can sort by the value -- which is what `simple_first' does, floating scalars
# above containers. A port that wired one to the other would pass `sort-keys'
# and fail `simple-first'.
check_eq $P/order-insertion '{"c": 1, "a": 2, "b": 3}' "$(pv order_insertion)"
check_eq $P/order-sort-keys '{"a": 2, "b": 3, "c": 1}' "$(pv order_sort_keys)"
check_eq $P/order-item-sort-key '{"a": 2, "b": 3, "c": 1}' "$(pv order_item_sort_key)"
check_eq $P/order-item-sort-key-desc '{"c": 1, "b": 3, "a": 2}' "$(pv order_item_sort_key_desc)"
check_eq $P/order-simple-first '{"w": 3, "y": 2, "x": {"k": 1}, "z": [1]}' "$(pv order_simple_first)"

# ------------------------------------------------- namedtuple, tuple, hooks --
# A NAMEDTUPLE IS A TUPLE, so the two knobs interact and the order they are
# consulted in is the behaviour. `namedtuple_as_object' (default True) makes it
# an OBJECT keyed by field name; turning it off drops it to the tuple rule, and
# `tuple_as_array' (default True) then decides between an array and a refusal.
check_eq $P/namedtuple-default '{"x": 1, "y": 2}' "$(pv namedtuple_default)"
check_eq $P/namedtuple-off '[1, 2]' "$(pv namedtuple_off)"
check_eq $P/namedtuple-off-no-tuple "TypeError" "$(pv namedtuple_off_no_tuple)"
check_eq $P/tuple-default '[1, 2]' "$(pv tuple_default)"
check_eq $P/tuple-as-array-off "TypeError" "$(pv tuple_as_array_off)"
check_eq $P/namedtuple-nested '{"p": {"x": 1, "y": 2}}' "$(pv namedtuple_nested)"

# A DATACLASS IS NOT A NAMEDTUPLE and simplejson has no rule for one; it reaches
# `default' like any other object and is refused. Recorded as measured rather
# than as the encoding a reader would assume from the two knobs above.
check_eq $P/dataclass-refused "TypeError" "$(pv dataclass_default)"

# `for_json' is the documented way an object names its own encoding, and it is
# OFF by default -- so both arms are pinned.
check_eq $P/for-json-on '{"x": 1}' "$(pv for_json_on)"
check_eq $P/for-json-off "TypeError" "$(pv for_json_off)"

# ------------------------------------------------------------ NaN / Infinity -
# THE DEFAULT IS THE OPPOSITE OF THE STANDARD LIBRARY'S, in both directions.
check_eq $P/nan-default-refused "ValueError" "$(pv nan_default_refused)"
check_eq $P/nan-allow-on '[NaN, Infinity, -Infinity]' "$(pv nan_allow_on)"
check_eq $P/nan-ignore '[null, null, null]' "$(pv nan_ignore)"
check_eq $P/nan-ignore-in-object '{"a": null}' "$(pv nan_ignore_in_object)"
check_eq $P/nan-decode-default '1|1|2|Expecting value' "$(pv nan_decode_default)"
check_eq $P/nan-decode-allow-on '[nan, inf, -inf]' "$(pv nan_decode_allow_on)"
check_eq $P/nan-decode-is-nan "yes" "$(pv nan_decode_is_nan)"

# -------------------------------------------------------- bigint as string ---
# THE 53-BIT WALL. A JSON integer wider than a double's mantissa does not
# survive a JavaScript consumer, so `bigint_as_string' emits it as a STRING. The
# boundary is what is asserted: 2**53-1 stays a number and 2**53 becomes a
# string, and `int_as_string_bitcount' moves that boundary explicitly.
check_eq $P/bigint-off '[9007199254740991, 9007199254740992]' "$(pv bigint_off)"
check_eq $P/bigint-on '[9007199254740991, "9007199254740992"]' "$(pv bigint_on)"
check_eq $P/bigint-negative '["-9007199254740992", -9007199254740991]' "$(pv bigint_negative)"
check_eq $P/bigint-bitcount '[15, "16"]' "$(pv bigint_bitcount)"
check_eq $P/bigint-huge-roundtrip '1180591620717411303424' "$(pv bigint_huge_roundtrip)"

# ------------------------------------------------------------- layout knobs --
# `indent' AND `separators' TOGETHER ARE THE PRETTY-PRINTER, and the trap is
# that indent changes the DEFAULT item separator: without it the default is
# `, ', with it the trailing space would leave whitespace at the end of every
# line, so simplejson drops it to `,'. Both are pinned, layout and all -- the
# probe reports newlines as the two characters `\n' and tabs as `\t', so the
# expectations below are exact without ever spanning a line.
check_eq $P/layout-compact '{"b": [1, 2], "a": 1}' "$(pv layout_compact)"
check_eq $P/layout-separators '{"b":[1,2],"a":1}' "$(pv layout_separators)"
check_eq $P/layout-indent2 '{\n  "b": [\n    1,\n    2\n  ],\n  "a": 1\n}' "$(pv layout_indent2)"
check_eq $P/layout-indent-tab '{\n\t"b": [\n\t\t1,\n\t\t2\n\t],\n\t"a": 1\n}' "$(pv layout_indent_tab)"
check_eq $P/layout-indent-sorted '{\n  "a": 1,\n  "b": [\n    1,\n    2\n  ]\n}' "$(pv layout_indent_sorted)"
check_eq $P/layout-indent-separators '{\n  "b": [\n    1,\n    2\n  ],\n  "a": 1\n}' "$(pv layout_indent_separators)"
check_eq $P/layout-empty-containers '{\n  "a": [],\n  "b": {}\n}' "$(pv layout_empty_containers)"

# ------------------------------------------------------- decoder failures ----
# EVERY DOCUMENTED REFUSAL, WITH ITS POSITION. The position is the half that
# matters: a decoder that raises the right exception at the wrong offset is
# useless to a caller trying to point at the byte, and it is exactly what a
# byte-versus-codepoint slip on a new arm would break. Each value is
# `pos|lineno|colno|msg', and `err-multiline-pos' is the one that can only be
# right if line and column are tracked separately from the offset.
check_eq $P/err-trailing '9|1|10|Extra data' "$(pv err_trailing)"
check_eq $P/err-unterminated '0|1|1|Unterminated string starting at' "$(pv err_unterminated)"
check_eq $P/err-bad-escape '3|1|4|Invalid \X escape sequence %r' "$(pv err_bad_escape)"
check_eq $P/err-empty '0|1|1|Expecting value' "$(pv err_empty)"
check_eq $P/err-expecting-value '4|1|5|Expecting value' "$(pv err_expecting_value)"
check_eq $P/err-expecting-colon "5|1|6|Expecting ':' delimiter" "$(pv err_expecting_colon)"
check_eq $P/err-multiline-pos '5|3|1|Expecting value' "$(pv err_multiline_pos)"
check_eq $P/err-is-valueerror "yes" "$(pv err_is_valueerror)"

# `strict' IS ABOUT CONTROL CHARACTERS and nothing else, which is worth saying
# because the name suggests a general pedantry it does not have. A raw newline
# inside a string is refused under the default and accepted with strict=False.
check_eq $P/strict-control-char '1|1|2|Invalid control character %r at' "$(pv strict_control_char)"
check_eq $P/strict-off-control-char "'a\\nb'" "$(pv strict_off_control_char)"

# A DUPLICATE KEY IS NOT AN ERROR in this decoder, under `strict' or otherwise:
# the last value wins. `object_pairs_hook' is the documented way to SEE both,
# and it is the only reason a caller who needs the refusal has anywhere to go.
check_eq $P/duplicate-key "{'a': 2}" "$(pv duplicate_key)"
check_eq $P/duplicate-key-strict "{'a': 2}" "$(pv duplicate_key_strict)"
check_eq $P/duplicate-key-pairs-hook "[('a', 1), ('a', 2)]" "$(pv duplicate_key_pairs_hook)"

# ------------------------------------------------------------ odds and ends --
# The remaining public surface, one case each: the HTML-safe encoder, RawJSON
# pass-through, the ordered object hook, the ASCII/Unicode pair, and iterables.
# Each is a documented feature the standard library has no equivalent for, so
# losing one would be a silent narrowing of the port.
# JSONEncoderForHTML ESCAPES `<', `>' and `&' AS \u SEQUENCES so the output
# cannot close the <script> element it is embedded in, and it escapes U+2028
# and U+2029 too -- line terminators in JavaScript but not in JSON, which would
# break the script without them. `encode-plain-html' is the contrast: the
# ordinary encoder leaves `</script>' exactly as it found it.
check_eq $P/encode-for-html '"\u003c/script\u003e"' "$(pv encode_for_html)"
check_eq $P/encode-for-html-sep '"\u2028\u2029"' "$(pv encode_for_html_sep)"
check_eq $P/encode-plain-html '"</script>"' "$(pv encode_plain_html)"
check_eq $P/raw-json '{"a": [1,2,3]}' "$(pv raw_json)"
check_eq $P/object-pairs-hook "OrderedDict({'b': 1, 'a': 2})" "$(pv object_pairs_hook)"
# `ensure_ascii' IS ON BY DEFAULT, so U+6C34 leaves as the SEVEN ASCII
# characters \u6c34 and this file can carry the expectation verbatim. Turned
# off it leaves as UTF-8, which no console under the C locale can be trusted to
# render -- so the probe reports those bytes as hex: 22, the three-byte encoding
# of U+6C34, 22.
check_eq $P/ensure-ascii-on '"\u6c34"' "$(pv ensure_ascii_on)"
check_eq $P/ensure-ascii-off-hex '22e6b0b422' "$(pv ensure_ascii_off_hex)"
check_eq $P/unicode-roundtrip "yes" "$(pv unicode_roundtrip)"

# A CODEPOINT ABOVE THE BMP IS EMITTED AS A SURROGATE PAIR, which is what JSON
# requires and what the decoder on the other side has to recombine. U+1D120 is
# \ud834\udd20.
check_eq $P/surrogate-pair '"\ud834\udd20"' "$(pv surrogate_pair)"
check_eq $P/iterable-as-array '[1, 2, 3]' "$(pv iterable_as_array)"
check_eq $P/iterable-default "TypeError" "$(pv iterable_default)"
check_eq $P/circular-refused "ValueError" "$(pv circular_refused)"
check_eq $P/circular-marker-cleared '[[1], [1]]' "$(pv circular_marker_cleared)"

# ----------------------------------------------------- the UPSTREAM suite ----
# THE SUBSTANCE OF THE PORT: the 146 tests the python3-simplejson-tests
# sub-package ships, run in-process against the shipped module. This is the most
# expensive case in the file -- one interpreter start plus three more that
# simplejson.tests.test_tool spawns as subprocesses -- so it gets the larger
# half of the suite's budget.
if [ ! -f "$UPSTREAM" ]; then
  bst_notok $P/upstream-present "upstream runner missing at $UPSTREAM"
else
  bst_ok $P/upstream-present
fi

bst_probe $P/upstream-run "$W/up" 2400 python3 "$UPSTREAM"

UOUT="$W/up"
uv() { grep "^$1=" "$UOUT" 2>/dev/null | head -n 1 | cut -d= -f2-; }

# GATED, AND THE GATE IS THE POINT. `upstream-clean' below asserts that the set
# of failing test ids is EMPTY -- which is also exactly what a run that never
# started produces. So the three cases here come FIRST and are what make it
# meaningful: the runner reached its last line, it ran the expected number of
# tests, and it said so itself (BRINTOS-2081).
check_eq $P/upstream-done "yes" "$(uv upstream_done)"
check_eq $P/upstream-ran "146" "$(uv upstream_ran)"
check_eq $P/upstream-ok "yes" "$(uv upstream_ok)"

check_eq $P/upstream-failures "0" "$(uv upstream_failures)"
check_eq $P/upstream-errors "0" "$(uv upstream_errors)"
check_eq $P/upstream-clean "" "$(uv upstream_bad_ids)"

# THE SKIPS ARE THE ACCELERATOR'S SHADOW, and they are asserted by NAME rather
# than by count. Seven test_speedups cases skip because `encoder.c_make_encoder'
# is None, and `TestMissingSpeedups' is added by the harness for the same
# reason. A run where this list SHRANK would mean the bbappend had stopped
# taking -- which is the one way this suite could go green while measuring the
# wrong code -- and a run where it GREW would mean a test had started skipping
# for some reason nobody has named.
check_eq $P/upstream-skipped "8" "$(uv upstream_skipped)"
check_eq $P/upstream-skip-ids \
  "simplejson.tests.TestMissingSpeedups.runTest,simplejson.tests.test_speedups.TestDecode.test_bad_bool_args,simplejson.tests.test_speedups.TestDecode.test_make_scanner,simplejson.tests.test_speedups.TestEncode.test_bad_bool_args,simplejson.tests.test_speedups.TestEncode.test_bad_encoding,simplejson.tests.test_speedups.TestEncode.test_bad_str_encoder,simplejson.tests.test_speedups.TestEncode.test_int_as_string_bitcount_overflow,simplejson.tests.test_speedups.TestEncode.test_make_encoder" \
  "$(uv upstream_skip_ids)"

check_eq $P/upstream-version "3.19.2" "$(uv upstream_version)"
check_eq $P/upstream-tests-file "$PKG/tests/__init__.py" "$(uv upstream_tests_file)"

# ------------------------------------------------------------------ the CLI --
# THE SHIPPED COMMAND-LINE DRIVER, IN ITS OWN PROCESS. simplejson/tool.py comes
# from the -tests sub-package and is reached as `python3 -m simplejson.tool',
# because this project declares no console script. The case measures something
# the probe structurally cannot: that the module is runnable as a program and
# resolves its own import of the package.
#
# THE FIXTURE IS READ BY PATH, NOT REDIRECTED. tool.py opens argv[1] itself, so
# there is no stdin redirect and none of the dup2(2)-returns-513 trap a redirect
# from the virtiofs root falls into.
#
# AND THE EXPECTED OUTPUT IS THE DECIMAL CLAIM MADE THROUGH THE CLI. tool.py
# runs `use_decimal=True' both ways over `sort_keys=True, indent="    "', so
# 1.100000000000000000001 must come back with all twenty-two digits -- a float
# path would print 1.1 -- while the keys come out sorted and the layout is the
# four-space one. Newlines are folded to `|' by `tr' inside a command
# substitution, which forks, so nothing here redirects in this shell.
check $P/tool-fixture-present test -s "$TOOLFIX"
check_eq $P/tool-output \
  '{|    "alpha": [|        1,|        {|            "a": null,|            "z": true|        }|    ],|    "beta": 1.100000000000000000001,|    "gamma": 12345678901234567890|}|' \
  "$(python3 -m simplejson.tool "$TOOLFIX" 2>&1 | tr '\n' '|')"

rm -rf "$W"