JET + Mooncake fixes for 1.12

[penelopeysm]

• Mooncake doesn't precompile on 1.12, which was causing CI to fail on julia-version = pre. This removes it from the test suite if the Julia version is a prerelease.

Previously, we knew that CI was failing on 1.12 because of Mooncake. However, removing Mooncake also flagged up a couple more errors that I had to resolve to get CI to pass:

• JET.jl has a new version, v0.10, that is intended for Julia 1.12. This PR also includes v0.10 in the allowed compat ranges for JET.jl so that the tests can run on pre. Previously, the JET tests on pre would fail as CI would attempt to install an older version of JET that wasn't forward-compatible. Thankfully, this doesn't require runtime checks because Pkg will automatically figure out the appropriate version of JET to install.

• Finally, this PR disables doctests on 1.12, because error messages vary from version to version and it can be very flaky to test correctly for them.

There is still one remaining test failure on 1.12, which is related to the use of Threads.threadid() in ThreadSafeVarInfo. I wrote up more about this problem in #924.

Supersedes: #872 #873 #875

[github-actions]

Benchmark Report for Commit 7363432

Computer Information

Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 4 × AMD EPYC 7763 64-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver3)
Threads: 1 default, 0 interactive, 1 GC (on 4 virtual cores)

Benchmark Results

|                 Model | Dimension |  AD Backend |      VarInfo Type | Linked | Eval Time / Ref Time | AD Time / Eval Time |
|-----------------------|-----------|-------------|-------------------|--------|----------------------|---------------------|
| Simple assume observe |         1 | forwarddiff |             typed |  false |                  9.1 |                 1.6 |
|           Smorgasbord |       201 | forwarddiff |             typed |  false |                772.0 |                33.0 |
|           Smorgasbord |       201 | forwarddiff | simple_namedtuple |   true |                412.2 |                44.9 |
|           Smorgasbord |       201 | forwarddiff |           untyped |   true |               1213.9 |                27.0 |
|           Smorgasbord |       201 | forwarddiff |       simple_dict |   true |               3406.0 |                22.1 |
|           Smorgasbord |       201 | reversediff |             typed |   true |               1487.8 |                29.2 |
|           Smorgasbord |       201 |    mooncake |             typed |   true |                987.4 |                 5.1 |
|    Loop univariate 1k |      1000 |    mooncake |             typed |   true |               5434.7 |                 4.2 |
|       Multivariate 1k |      1000 |    mooncake |             typed |   true |                986.5 |                 9.1 |
|   Loop univariate 10k |     10000 |    mooncake |             typed |   true |              60904.6 |                 3.7 |
|      Multivariate 10k |     10000 |    mooncake |             typed |   true |               8538.1 |                10.1 |
|               Dynamic |        10 |    mooncake |             typed |   true |                130.0 |                13.0 |
|              Submodel |         1 |    mooncake |             typed |   true |                 13.2 |                 6.9 |
|                   LDA |        12 | reversediff |             typed |   true |                464.6 |                 5.6 |

[github-actions]

DynamicPPL.jl documentation for PR #921 is available at:
https://TuringLang.github.io/DynamicPPL.jl/previews/PR921/

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.10%. Comparing base (b0ff259) to head (7363432).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #921   +/-   ##
=======================================
  Coverage   85.10%   85.10%           
=======================================
  Files          36       36           
  Lines        3954     3954           
=======================================
  Hits         3365     3365           
  Misses        589      589           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coveralls]

Pull Request Test Coverage Report for Build 15098406626

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 22 unchanged lines in 11 files lost coverage.
• Overall coverage remained the same at 85.19%

---

Files with Coverage Reduction	New Missed Lines	%
ext/DynamicPPLEnzymeCoreExt.jl	1	0.0%
ext/DynamicPPLForwardDiffExt.jl	1	63.64%
src/sampler.jl	1	89.23%
src/simple_varinfo.jl	1	75.14%
src/varnamedvector.jl	1	89.36%
src/contexts.jl	2	74.79%
src/logdensityfunction.jl	2	52.27%
src/model.jl	2	84.17%
src/utils.jl	2	73.8%
src/values_as_in_model.jl	3	59.52%

Totals
Change from base Build 15098141060:	0.0%
Covered Lines:	3365
Relevant Lines:	3950

---

💛 - Coveralls

[mhauru]

Definitely happy with the JET thing, probably happy with the Mooncake thing, unsure about the doctests. Won't we have the same problem of error message variation once the prerelease becomes the next release, and our CI will run both that and min?

[mhauru]

What does it mean for something to be a weak dependency of tests?

[penelopeysm]

To be honest, no idea now, I remember needing to add it to satisfy something. It could have been because of the compat entry i.e. if we remove the Mooncake compat entry from test/Project.toml it might be fine. Let me try that

[penelopeysm]

Won't we have the same problem of error message variation once the prerelease becomes the next release, and our CI will run both that and min?

That's true. I contemplated doing it in this PR but didn't — the correct solution IMO is for the doctests to only be built on the current version, and I think the easiest way to do that is to do the doctests as part of the doc building workflow rather than the test workflow. Would you be on board with that?

[mhauru]

Hmm, what about a separate workflow just for doctests? Annoying code duplication? They do feel a lot more like tests than docs to me, build-wise.

[penelopeysm]

A little bit of workflow yaml code duplication in exchange for not having weird logic inside test/runtests.jl seems like a win to me, let's go with that.