feat: upgrade llama.cpp from b10909 to b10938

[bernardladenthin]

Summary

• Bumps the pinned llama.cpp version from b10909 to b10938 (the latest upstream release) across all four pin sites, and appends six row pairs to the breaking-changes history — one per chunk.
• The largest bump this repo has taken in a while: 29 upstream commits, 137 files, 1003 KiB — ten times the runbook's 100 KiB per-step threshold, so it is walked as six chunks, six commits.
• Two chunks are single commits that exceed the threshold on their own and cannot be subdivided. One of them is harmless; the other is where all the risk in this range lives.

#	Step	Size / commits	What it is
1	b10909 → b10919	93 KiB / 10	server-models.cpp rewrite (#28555), PCH + unity build (#28091)
2	b10919 → b10920	541 KiB / 1	#28589 hexagon row-split — empty review surface
3	b10920 → b10927	94 KiB / 7	cpp-httplib → 0.56.0 (#28787)
4	b10927 → b10933	41 KiB / 6	server fixes, Jinja dot-property literals
5	b10933 → b10934	215 KiB / 1	common_schema internal representation (#28736)
6	b10934 → b10938	18 KiB / 4	LOG_JSON macro, qwen3-coder parser fix

Chunk 5 is the whole risk, and it lands clean

#28736 replaces raw common_json schema handling with a typed common_chat_schema tree. In one commit it touches three patch targets and two priority-list rows: common/chat.h, common/peg-parser.{cpp,h}, common/json-schema-to-grammar.*, common/arg.cpp, tests/CMakeLists.txt, tools/server/server-schema.cpp, plus a new common/json-schema.{h,cpp} and a restructured common/parsers/** (16 model parsers).

Why it is safe here — each point established, not inferred:

1. common/chat.h (priority row 2) is purely additive. One new declaration, common_chat_tool_parameters(const common_json &). No existing signature moved.
2. common/peg-parser.cpp is patches/0011's file, but the edits are disjoint from the patch. Every change is in the schema machinery — dump_impl's Schema(...) rendering, common_peg_parser_builder::schema, and build_grammar's schema_delegates lambda (which collapses ~25 lines of raw-JSON type sniffing into s.raw && s.node->may_be_string()). 0011 modifies the until-parser's UTF-8 INVALID branch, which survives intact — the paired is_lenient()/INVALID structure is still at lines 482/487 and 521/527 of the pristine b10938 file.
3. common/json-schema-to-grammar.h is on the documented safe-to-skip list (not used directly by project code).
4. The wire surface did not move, checked mechanically rather than by reading: server-schema.cpp's field set is 68 → 68 identical, server-task.cpp's response keys 142 → 142 identical, and repeat_last_n/dry_penalty_last_n keep set_hard_limits(0, INT32_MAX). That is the silent-contract-change class that cost getMetrics() hundreds of builds; it does not apply here.
5. New common/json-schema.* and common/parsers/** sources join common/CMakeLists.txt, i.e. the llama-common library this project links. This project's CMakeLists.txt never enumerates common/ sources, so they are picked up with no project-side change.

Patches: all ten apply, tested against the target before anything was edited

Two patch targets churn hard in this range — tools/server/server-models.cpp (+277/−200, patches/0008, touched in three separate chunks) and common/peg-parser.cpp (patches/0011). So the patch set was applied in filename order to a pristine b10938 worktree first, before a single pin site was edited: all ten applied cleanly.

All four standing drop-checks were run against the pristine tag, because the fail-loud applier detects "does not apply" but never "upstream already fixed this":

Patch	Check	Result at b10938
0001	common_params_parse_main in common/arg.h	0 occurrences; WIN32 override still at common/arg.cpp:1282 — unmoved despite three edits to that file in this range → still required
0010	{"vocab_type", meta.model_vocab_type}	still uncast at server-context.cpp:4554 → still required
0012	split_sum zero guard	still a bare splits[i] /= split_sum; at src/llama-model.cpp:1491 → still required
0013	the three s390x VXE helpers	still unguarded at lines 73/77/83 → still required

0013 remains filed-but-unmerged upstream as ggml-org/llama.cpp#28775. When it merges, the first tag carrying it aborts the configure and the response is to delete the patch, not refresh it.

Two other items worth a reviewer's eye

• cpp-httplib 0.56.0 (chunk 3). vendor/cpp-httplib/httplib.cpp is compiled directly into libjllama — it is our translation unit, not upstream's, and it is the 16.6k-line file the CI-cache notes single out as a build-time cost. Exposure is confined to compiling and linking: only upstream's server-http.cpp includes it, this project's own C++ never does, and no SSL is configured (CPPHTTPLIB_OPENSSL_SUPPORT left undefined), so the 0.56.0 TLS surface is not reached.
• PCH + unity build (chunk 1, #28091) is the build-system class CLAUDE.md warns a header diff cannot catch. It does not reach this project: the upstream server .cpp files are added to our own jllama target rather than linked from upstream's, so their target_precompile_headers never applies; llama-common is consumed as a library, where PCH is an internal detail.

Test plan

• Affected unit / integration tests pass locally
• CI is green on this branch
• Docs / CHANGELOG updated where applicable

Verified on Linux x86_64 from a fresh configure (build directory removed first, so the applier took its clean-tree path and wrote a new stamp):

• Patch applier — stamp at head f1e44dcc11d8802d107bd7331a3d3fd3e6f57b93 (= b10938) with all ten SHA-256 lines; no "does not apply cleanly" abort.
• Build — full cmake --build --config Release, zero errors, including cpp-httplib 0.56.0 and the common_schema restructure. This is the step that actually tests this range: the patches applying was necessary but not sufficient, since a new upstream schema type could have broken a signature json_helpers.hpp / jni_helpers.hpp depend on.
• C++ unit suite — ctest: 537/537. Two of those are load-bearing here: ContentOnlyParseUtf8 (the runnable guard for 0011, in the very file #28736 restructured) and test_model_split (0012) — green means the patches still work, not merely apply.
• Wire-name extraction — unchanged at 138 CLI / 57 request / 15 trainer names (10 OAI_LAYER keys swept for upstream readers against b10938's sources), so no registry drifted.
• JNI surface — nm -D: 40 Java_* exports.
• NativeLibraryLoadSmokeTest — 4/4, 0 skipped, run after a clean so nativeBuildInfoMatchesPinnedVersionConstant compared the rebuilt binary against the new constant rather than a stale class.
• Full Java suite — mvn test: 1755 run, 0 failures, 0 errors (269 skipped — the model-gated classes; no GGUF in this sandbox).
• Gates — SpotBugs 0 findings; spotless:check clean; javadoc:jar BUILD SUCCESS.

Related issues / PRs

Refs ggml-org/llama.cpp#28775 — the upstream carry of patches/0013, still open.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes

Files changed (5, all six commits combined)

File	Change
llama/CMakeLists.txt	GIT_TAG b10909 → b10938
llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java	LLAMA_CPP_VERSION constant + 3 javadoc mentions
README.md	badge + link
CLAUDE.md	pinned-version line + 3 incidental mentions
docs/history/llama-cpp-breaking-changes.md	six appended row pairs (one per chunk)

CHANGELOG.md is deliberately untouched: it records consumer-visible behaviour, and llama.cpp pin bumps are not recorded there.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH

---

Generated by Claude Code

[bernardladenthin]

Standing non-PR check failures

The four reds on this head — Verify GPG signing key (both), analyze (CodeQL), claude-review, plus the License Compliance commit status — are the same standing set documented in full on #434: #434 (comment)

Re-verified on this head rather than assumed: both GPG jobs failed in 2 seconds with no steps executed (the signature of GitHub refusing a job whose environment: maven-central is unavailable on a PR branch — publish.yml:119 and :233), and claude-review failed in 20 s the same way it has since 2026-09-09.

None is caused by this diff, which changes five files: a CMake tag, a Java constant, and three docs. Not re-running them — all are deterministic by construction, so a re-run would spend CI minutes and change nothing. No fix ported, for the reasons given in the #434 comment: each one's fix lives outside a llama.cpp version bump and would widen this PR.

The checks that do gate this change — C++ Tests, the platform build/test matrix, Java Tests *, the fat-jar smokes — run behind Start gate (abort window) and are reported separately. They matter more than usual here: this range bumps cpp-httplib to 0.56.0, which compiles into libjllama on every platform, and only Linux x86_64 was verified locally.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud