Enzyme ext: add forward rule for FwdConfig{false, false, …}

[ChrisRackauckas-Claude]

Summary

Adds the missing forward-mode EnzymeRules case for FwdConfig{NeedsPrimal=false, NeedsShadow=false, W, RA, SZ}. The extension previously only covered the three combinations with at least one of NeedsPrimal / NeedsShadow set, so Enzyme calls with both false fell through to the default differentiation path and errored when the wrapped FunctionWrappersWrapper only held plain-Float64 signatures.

Motivating failure

OrdinaryDiffEq.jl v7 Downstream CI hit this while solving Rosenbrock32(autodiff = AutoEnzyme(mode = Enzyme.Forward, function_annotation = Const)) over an IIP RHS:

MethodError: no method matching forward(
    ::EnzymeCore.EnzymeRules.FwdConfigWidth{1, false, false, false, false},
    ::EnzymeCore.Const{FunctionWrappersWrappers.FunctionWrappersWrapper{
        Tuple{FunctionWrappers.FunctionWrapper{Nothing,
            Tuple{Vector{Float64}, Vector{Float64}, SciMLBase.NullParameters, Float64}}}, …}},
    ::Type{EnzymeCore.Const{Nothing}},
    ::EnzymeCore.Duplicated{Vector{Float64}},
    ::EnzymeCore.Duplicated{Vector{Float64}},
    ::EnzymeCore.Const{SciMLBase.NullParameters},
    ::EnzymeCore.Const{Float64})

The SciMLBase v3 path (used on the v7 branch) wraps IIP RHSs with a narrower set of FW signatures than v2, which exposes this gap.

Fix

A 4th EnzymeRules.forward method for FwdConfig{false, false, W, …} that runs the primal for its side effects and returns nothing — what Enzyme's default rule would have done if it could have dispatched through the raw wrapper.

Test

Added a regression test that calls EnzymeRules.forward directly with the {false, false} config against a FWW wrapping an IIP two-arg function. Without the fix the test reproduces the exact MethodError from the v7 Downstream CI; with the fix it passes and confirms the primal side effect (mutation of du) happened while the shadow buffer was left untouched.

(Note: test/enzyme_tests.jl has an unrelated pre-existing failure in the batch-width=2 suite — TypeError: expected Tuple{Float64, Float64}, got @NamedTuple — looks like an EnzymeCore shape change. Out of scope for this PR.)

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Extended the PR to cover the remaining reverse-mode gaps I found while auditing the extension:

New augmented_primal methods:

• RT <: Const — for non-differentiated returns (e.g. IIP functions returning Nothing; reverse-mode mirror of the forward {false, false} case). Runs the primal; no shadow or tape.
• RT <: Duplicated{T} — returns primal and zero-initializes the return shadow.
• RT <: BatchDuplicated{T, W} — same with NTuple of W zero-shadows.

New reverse methods:

• dret::Const with uniform Active args.
• dret::Const with mixed Annotation args.

Both return nothing per arg since there is no return derivative to propagate.

Each new path has a dedicated test that constructs a concrete RevConfig and calls the rules directly, asserting on the AugmentedReturn fields and reverse gradient shape.

Not covered (noted for future PRs):

• Batched reverse with dret::Active{NTuple{W, T}} — I sketched a rule but couldn't construct Active{NTuple} cleanly through Enzyme's public API to write a meaningful test, and the correct shape Enzyme actually passes for batched reverse gradients needs more investigation. Dropped from this PR.
• Reverse through Duplicated args on IIP functions with Const return — would require either delegating to Enzyme.autodiff on the unwrapped function or manually inverting the primal's forward action on the arg shadows. Not landing in this PR.

Local test summary after the changes: 25 passed, 1 errored (the 1 error is the pre-existing Enzyme batch forward mode (width > 1) test that's failing with a TypeError: expected Tuple{Float64, Float64}, got @NamedTuple — looks like an EnzymeCore shape change; out of scope here).

[ChrisRackauckas-Claude]

Important correction pushed.

The {false, false} rule I originally added ran the wrapped primal for side effects and returned nothing. That broke OrdinaryDiffEq.jl v7's downstream Rosenbrock23/Rodas4/Rodas5/Veldd4 tests with AutoEnzyme(Forward, function_annotation = Const) — errors jumped 4–9 orders of magnitude above the expected tolerances. The reason: Enzyme dispatches with FwdConfig{false, false, …} when it wants no output (no primal, no shadow), but the rule was mutating IIP Duplicated buffers (SciML's du) and polluting state that Enzyme's other forward calls rely on.

Fix: make the rule a strict no-op — return nothing without invoking the wrapped function at all. Regression test updated to assert the primal counter stays at 0 and the IIP / shadow buffers are untouched.

Local test summary: 26 passed, 1 errored (still the pre-existing batch forward mode (width > 1) NamedTuple issue, unrelated).

[ChrisRackauckas-Claude]

Closing in favor of a fresh single-commit PR — the intermediate revision on this branch ran the wrapped primal in the {false, false} rule and would have broken downstream IIP callers; replaced with a new PR that lands only the verified no-op version.