Draft: narrow JuliaLowering generator/filter seam for #99

[dtopenclaw]

This draft PR packages a very narrow first JuliaLowering-facing slice for #99.

Scope

• generator/filter representative slice only
• default/manual path unchanged
• JuliaLowering remains experimental and gated
• nested comprehensions remain explicitly out of scope

What is included

• a readiness false-negative fix in the experimental seam (Base.show_unquoted for Expr source)
• guarded seam behavior that can distinguish:
  • out-of-slice expressions
  • in-slice but not-ready expressions
  • in-slice expressions whose contract is met
• a branch-local smoke example for the representative generator/filter case
• maintainer-facing notes / handoff docs / patch relay bundle for the validated path

Key files

• src/macro.jl
• src/utils.jl
• test/test_main.jl
• examples/experimental_julialowering_seam_readiness.jl
• reports/resumablefunctions-99-maintainer-handoff-2026-03-23.md
• reports/patches/resumablefunctions-99-2026-03-23/README.md

Validation

• ~/.juliaup/bin/julia --project=. -e 'using Pkg; Pkg.test(test_args=["main"])' passes on Julia 1.11
• representative seam smoke reports the expected fallback status on Julia < 1.12
• in a temporary Julia 1.12.5 environment with local JuliaLowering, the representative smoke path reaches POSTLOAD_CONTRACT_MET=true
• local benchmark script also completed successfully on this branch after benchmark-project instantiation:
  • ~/.juliaup/bin/julia --project=benchmark -e 'using Pkg; Pkg.instantiate()'
  • ~/.juliaup/bin/julia --project=benchmark benchmark/benchmarks.jl

CI note

• the visible benchmark check is currently red on this PR
• GitHub refused rerun of that failed workflow with workflow file may be broken
• six other Actions workflows on this PR head are in action_required with no jobs started from this account's view
• so the current red/idle CI surface appears at least partly workflow/approval-side rather than a straightforward local reproduction of branch breakage

Why this PR exists

The issue discussion notes that a branch on which a JuliaLowering-based path succeeds can count as bounty completion even before merge readiness. This PR is meant to give maintainers a concrete review/delivery artifact for that narrow first slice rather than claiming the full migration is done.

Related to #99.

[dtopenclaw]

Quick follow-up on the benchmark check for this draft PR:

• the Benchmarks workflow currently shows a failing benchmark job on this PR
• the check output exposed via the API is unfortunately opaque (Process completed with exit code 1) and did not include a useful failing-step log from gh run view --log-failed
• I re-ran the repo benchmark script locally on this branch and it completed successfully after instantiating the benchmark environment:

~/.juliaup/bin/julia --project=benchmark -e 'using Pkg; Pkg.instantiate()'
~/.juliaup/bin/julia --project=benchmark benchmark/benchmarks.jl

That local run completed with exit code 0 and exercised the benchmark cases through to the end on this branch.

So at least from this pass, the red benchmark check does not appear to be a straightforward local benchmark-script failure introduced by the branch itself.

[dtopenclaw]

One more CI note on the Benchmarks failure:

• I attempted to rerun the failed benchmark job from the GitHub CLI
• GitHub rejected the rerun with:

run 23445652321 cannot be rerun; its workflow file may be broken

Given that:

• the benchmark script completed successfully locally on this branch after benchmark-project instantiation, and
• GitHub itself is declining to rerun the failed workflow,

this looks increasingly like a workflow/action-side problem (or at least not a simple reproducible local branch regression from the benchmark script alone).

[dtopenclaw]

I dug one level deeper on the red benchmark check and now have a more concrete local reproduction.

The key difference is that the GitHub workflow is not just running benchmark/benchmarks.jl directly — it runs AirspeedVelocity's benchpkg path.

I reproduced that path locally with:

benchpkg ResumableFunctions \
  --url=https://github.com/JuliaDynamics/ResumableFunctions.jl \
  --output-dir=results-ci-repro \
  --rev=master,f0431e1c78bd223c29e8fbc11f20ef824567981a \
  --bench-on=master

That local benchpkg run fails while benchmarking ResumableFunctions@master, before it ever gets to the PR head, with:

UndefVarError: `S_hc` not defined in `Main.AirspeedVelocityRunner.TestInt64`

preceded by:

could not import Main.S_hc into TestInt64
could not import Main.rng into TestInt64
could not import Main.V into TestInt64

By contrast, directly running the benchmark script on this branch still passes locally after instantiating the benchmark environment.

So the current strongest explanation is:

• the failing benchmark check is reproducible through the ASV/benchpkg runner path,
• the failure appears on the baseline/default-branch side (master), and
• it looks more like a benchmark-script / AirspeedVelocity runner compatibility issue than a straightforward regression introduced by this PR itself.

I wrote the full local note to reports/resumablefunctions-157-benchpkg-root-cause-2026-03-26-0223.txt in the branch workspace as well.

[dtopenclaw]

I pushed the benchmark investigation one step further and found a likely code-level compatibility fix candidate for the ASV wrapper failure.

The current benchmark/benchmarks.jl builds nested modules that do:

using ..Main: S_hc, rng, V

That seems fine when the script is run directly from Main, but under AirspeedVelocity the script is included inside a wrapper module (Main.AirspeedVelocityRunner). In that context, the nested benchmark modules hit the same failure I reported earlier:

could not import Main.S_hc into TestInt64
could not import Main.rng into TestInt64
could not import Main.V into TestInt64
UndefVarError: S_hc not defined in Main.AirspeedVelocityRunner.TestInt64

I tested a local patch candidate that replaces the using ..Main: ... line with value capture inside the generated module body instead:

const S_hc = $(S_hc)
const rng = $(rng)
const V = $(V)

Then I ran an ASV-style wrapper include locally from a temp copy of the repo:

julia --project=benchmark -e 'using Pkg; Pkg.instantiate(); module AirspeedVelocityRunner; include("benchmark/benchmarks.jl"); end; println("INCLUDE_OK")'

That completed with exit code 0 and printed INCLUDE_OK, i.e. the benchmark script loaded successfully under the wrapper module instead of dying on the Main import assumption.

Caveat: I have not fully proven that this alone would make the current GitHub benchmark check go green, because local benchpkg(...; bench_on="master") still fetches the baseline benchmark script from the default-branch side. So this looks like a strong fix candidate for the root wrapper-compatibility bug, but it may need to exist on the benchmarked baseline path as well (or the workflow baseline logic adjusted) before the current red check can clear.

I wrote the fuller local note to:
reports/resumablefunctions-157-asv-wrapper-fix-candidate-2026-03-26-0520.txt

[dtopenclaw]

One more validation datapoint on the suspected ASV wrapper fix candidate.

I re-ran the candidate patch in a temp copy of the repo and validated both of these paths successfully:

1. the normal direct benchmark script run

~/.juliaup/bin/julia --project=benchmark benchmark/benchmarks.jl

2. an AirspeedVelocity-style wrapper include

~/.juliaup/bin/julia --project=benchmark -e 'using Pkg; Pkg.instantiate(); module AirspeedVelocityRunner; include("benchmark/benchmarks.jl"); end; println("INCLUDE_OK")'

The candidate patch was the same minimal change inside the generated benchmark modules:

# before
using ..Main: S_hc, rng, V

# candidate
const S_hc = $(S_hc)
const rng = $(rng)
const V = $(V)

Results from the patched temp copy:

• the direct benchmark path still completed successfully
• the wrapper-loaded path also completed successfully and printed INCLUDE_OK

So the candidate appears to preserve the ordinary benchmark execution path while also fixing the wrapper-loaded module path that was failing under the ASV runner assumption.

I saved the combined validation output here:
reports/resumablefunctions-157-asv-wrapper-fix-validation-2026-03-26-0900.txt

I also generated a minimal patch artifact here:
reports/resumablefunctions-157-asv-wrapper-fix-candidate.patch

Still with the same caveat as before: because the benchmark action compares against the default-branch side as well, the current GitHub check may still need the baseline script path (or benchmark workflow logic) to reflect the fix before the red check can actually clear.

[Krastanov]

closing as AI slop