[RefuX]

Slang 2026.13 → 2026.14.1, and the 0.0.7 release that ships it.

Two commits: the regeneration, produced and verified by the Slang version bump workflow, and the version bump on top.

The regeneration (9536dcf)

Every derived artifact re-made from v2026.14.1: the natives pin, all six per-platform manifests, the ABI model and lock, the generated Java, and PINNED_SLANG_VERSION. All three version pins moved together, so the ABI floor and the shipped binaries converge at 2026.14.1 — as they should after a full regen, and unlike a natives-only bump where the floor legitimately lags.

127 files changed, but only ten are substantive; the rest is a javadoc header line per generated file. The ABI lock diff is exactly three facts:

-enum CompilerOptionName CountOf 156
+enum CompilerOptionName CountOf 158
+enum CompilerOptionName DebugInfoIncludeSource 157
+enum CompilerOptionName SeparateDebugInfoOutput 156

That is the arc from #1 closing. The CountOf move is what tripped the drift canary as a false alarm; it is now recorded as what it always was — a derived count sentinel shifting because two options were legally appended — and the append-only lock enforced cleanly rather than failing.

Only two additions, not the six the canary reported. The canary watches master; this targets the release. SLANG_LANGUAGE_VERSION_202A/202B/202C/NEXT are in master's header and not in v2026.14.1 — verified against both. Both tools doing their distinct jobs.

The release (2aa2885)

gradle.properties → 0.0.7, which covers the library and both natives artifacts since it is the single source of truth for all of them. Plus the README's nine coordinate references, and DESIGN.md's Slang baseline row.

The other v2026.13 mentions in DESIGN.md are deliberately untouched — they date an API scan, a vtable-slot appendix and a resolved risk entry, so updating them would falsify history rather than refresh it. Same for the resolved in 0.0.6 row.

Verification

The branch was pushed by the workflow only after :slang:test passed against the new binaries on all four platforms CI covers (linux-x86_64, linux-aarch64, windows-x86_64, macos-aarch64), each leg re-downloading its natives so the freshly recorded manifests were verified rather than merely written.

Locally on windows-x86_64, on the release commit: 34/34 tests, nothing skipped, both the C export and COM vtable paths reporting the new build tag.

$ unzip -p slang-java-0.0.7.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Implementation-Title: slang-java
Implementation-Version: 0.0.7
Slang-Version: 2026.14.1

Notes

This was the first real execution of the bump workflow, and it validated the whole chain in one go: Xcode's libclang found with no setup, all six triples cross-validated, the append-only lock enforced against a genuine new release, and the patch transported to the Windows leg intact — the core.autocrlf pin earning its place.

After merge, the release itself is a v0.0.7 tag, which release.yml publishes to Maven Central auto-released.

🤖 Generated with Claude Code

[github-actions]

Qodana for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either:

• Register at Qodana Cloud and configure the action
• Use GitHub Code Scanning with Qodana
• Host Qodana report at GitHub Pages
• Inspect and use qodana.sarif.json (see the Qodana SARIF format for details)

To get *.log files or any other Qodana artifacts, run the action with upload-result option set to true,
so that the action will upload the files as the job artifacts:

      - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2026.1.3
        with:
          upload-result: true

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions