Things to check in 1.12

[Technici4n]

Some comments from the 1.12 update PR #714, to be checked at some point.

• Resizing bb_code.debuginfo.codelocs to 3n in bbcode.jl seems like a quick fix for incorrect handling of line numbers elsewhere.
• One of the @zero_derivative calls for logging in avoiding_non_differentiable_code.jl might be unnecessary.
• The integration testing for invalid global ref errors test is currently disabled for 1.12, is this the right thing to do?
• Why was has_equal_data_internal added for Method, CodeInstance and MethodInstance?
• resolve_unbound_globalrefs needs to be checked again.

[yebai]

Warning

The comments below are by Copilot. It may not be entirely accurate, but it is still useful, as it is more detailed than the above.

Analysis of the 5 open items (from PR #714 review comments + source)

All 5 items remain in the current codebase. Here's what I found for each:

---

1. codelocs resizing to 3n in bbcode.jl (lines 668–677)

In Julia 1.12+, debuginfo.codelocs changed format from one integer per instruction to three integers per instruction (flattened), so a valid vector has length 3n for n instructions.

The current code handles both > 3n (truncate) and < 3n (pad with zeros) cases. Technici4n questioned why the vector ever has the wrong size — if Mooncake constructs it properly via BBCode, it should always be exactly 3n. serenity4 never answered whether there is a genuine upstream case where this occurs.

Suspicion: This is a defensive band-aid. The root cause is likely in how BBCode is constructed from IRCode (or vice versa) — Technici4n raised new_inst_vec as a potential culprit too. Worth auditing the IRCode → BBCode → IRCode round-trip to see if codelocs is ever mis-sized for a legitimate reason.

---

2. Possibly unnecessary @zero_derivative for logging (avoiding_non_differentiable_code.jl, lines 63–74 vs 94+)

There are multiple @zero_derivative rules for CoreLogging dispatch chains. Technici4n asked whether the Core._call_latest + handle_message rule (lines 63–74) was made redundant by the earlier current_logger_for_env / shouldlog rules. mhauru replied he tried both independently and they weren't individually sufficient, but couldn't explain why.

The 1.12+ section adds handle_message_nothrow and its kwcall variant (lines 76–92). Worth checking whether the 1.12 logging path goes through handle_message_nothrow exclusively, which would make the older Core._call_latest + handle_message rule dead code on 1.12.

---

3. "Integration testing for invalid global ref errors" disabled on 1.12 (test/interpreter/reverse_mode.jl, lines 393–399)

The test is silently skipped on 1.12+ — the testset body becomes a no-op:

@testset "integration testing for invalid global ref errors" begin
    VERSION < v"1.12-" && @test_throws(
        Mooncake.Mooncake.MooncakeRuleCompilationError,
        Mooncake.build_rrule(Tuple{typeof(Mooncake.TestResources.non_const_global_ref),Float64})
    )
end

The original test validated that a non-const global ref causes a compilation error. serenity4's hypothesis was that Julia 1.12's partitioned bindings system may have changed how this case is handled. This needs verification against 1.12 to decide whether to: (a) re-enable the test, (b) update the expected error type, or (c) remove it as obsolete. A silently skipped test gives false confidence.

---

4. has_equal_data_internal for Method, CodeInstance, MethodInstance (test_utils.jl, lines 279–285)

for T in (:(Core.Method), :(Core.CodeInstance), :(Core.MethodInstance))
    @eval function has_equal_data_internal(
        x::$T, y::$T, equal_undefs::Bool, d::Dict{Tuple{UInt,UInt},Bool}
    )
        return x == y
    end
end

serenity4 added these because comparing Method/CodeInstance/MethodInstance via the generic has_equal_data_internal (which recurses into struct fields) caused infinite recursion and bricked the Julia session. The fallback to == avoids that. However, serenity4 explicitly said "I don't remember exactly which case required it, or if any really requires it at all. Feel free to remove or adjust."

What to check: Whether these types actually appear in tangent/primal data being compared during tests, and if so, whether x == y gives the right semantics for test assertions.

---

5. resolve_unbound_globalrefs needs re-checking (ir_normalisation.jl, lines 247–283)

The function is marked # XXX: this is probably unsound, but the best workaround so far. It patches GlobalRefs that CC.verify_ir considers unbound within the IR's valid_worlds range by resolving them to their current runtime value, so that verify_ir passes.

The concern: This bakes in a runtime value at compile time, which is unsound if the binding changes across world ages — and Julia 1.12 explicitly allows redefinition of const bindings across world ages. Technici4n raised the possibility that this becomes obsolete if we set the IR's valid_worlds to just the interpreter's world age, which would mean all bindings valid at that point pass verify_ir without needing this workaround.

Risk level: High — could silently produce incorrect gradients for code that redefines bindings.

---

Summary

#	File	Nature	Priority
1	bbcode.jl:668–677	Defensive band-aid, root cause unclear	Medium
2	avoiding_non_differentiable_code.jl:63–74	Possibly redundant rule	Low
3	test/interpreter/reverse_mode.jl:393	Silently disabled test	Medium
4	test_utils.jl:279–285	Possibly over-broad short-circuit	Low
5	ir_normalisation.jl:248	Marked unsound, may be fixable properly	High

Item 5 is the most consequential — it is explicitly marked unsound and could silently produce incorrect gradients. Item 3 is the most immediately actionable — a no-op testset should either be fixed or deleted.