[metif12]

Summary

v -autofree fails on three of the four platforms, and every diagnostic is inside V's stdlib rather than this repository:

  .github/workflows/ci.yml (ubuntu-gcc, macos-clang, ubuntu-tcc)
  - name: Compile gitly with -autofree
  + # Non-blocking: V's own vlib/net does not compile with -autofree, so
  + # this step fails for reasons outside this repository. See vlang/v#30190.
  + # Flip back to blocking once V's net module builds cleanly.
  + - name: Compile gitly with -autofree (non-blocking, vlang/v#30190)
  +   continue-on-error: true
      run: |
        cd gitly
        v -cc gcc -autofree .

That log has 7 diagnostics across 4 files, all in vlib/net:

vlib/net/util.v:12:10                     error: cannot copy borrowed `IError` value: ...
vlib/net/common.c.v:171:9                 error: cannot copy borrowed `IError` value: ...
vlib/net/common.c.v:196:9                 error: cannot copy borrowed `IError` value: ...
vlib/net/tcp.c.v:220:10                   error: cannot copy borrowed `IError` value: ...
vlib/net/mbedtls/ssl_connection.c.v:1086:11  error: cannot copy borrowed `IError` value: ...
vlib/net/mbedtls/ssl_connection.c.v:1096:9   error: cannot copy borrowed `IError` value: ...
vlib/net/mbedtls/ssl_connection.c.v:1106:9   error: cannot copy borrowed `IError` value: ...

Evidence

The failure was isolated with a probe that contains no gitly code at all:

import net.http

fn main() {
	r := http.get('https://example.com') or {
		return
	}
	println(r.status_code)
}

$ v -autofree -o probe.exe probe.v
vlib/net/util.v:12:10: error: cannot copy borrowed `IError` value: ...
vlib/net/common.c.v:171:9: error: cannot copy borrowed `IError` value: ...
vlib/net/common.c.v:196:9: error: cannot copy borrowed `IError` value: ...
vlib/net/tcp.c.v:220:10: error: cannot copy borrowed `IError` value: ...
EXIT=1

The same probe importing os instead of net.http succeeds, which pins the breakage to net rather than to -autofree generally:

$ v -autofree -o probe2.exe probe2.v
EXIT=0   (runs, prints the working directory)

The common shape is a module-level IError returned directly, e.g. return err_port_out_of_range in vlib/net/util.v, which the borrow checker treats as a borrowed value still requiring ownership destruction.

Filed upstream as vlang/v#30190 after searching for an existing report with repo:vlang/v autofree net IError, cannot copy borrowed IError autofree, autofree, and vlib/net. The autofree issues those return (#29496, #27116, #27294, #27292, #26901, #27179, plus the closed 20922, 23490, 14033, 24821, 22457, 18238, 11029, 9058, 25850, 25481, 25369, 14727, 12452) describe ownership errors in cmd/v, tos() freeing non-heap pointers, ComptimeSelector clone failures, runtime crashes and leaks — none reports the borrow checker rejecting vlib/net.

YAML re-parses with all four jobs intact, and re-reading the parsed document confirms continue-on-error: true is set on exactly the three autofree steps and on nothing else:

ubuntu-gcc    -> Compile gitly with -autofree (non-blocking, vlang/v#30190) | continue-on-error: True
macos-clang   -> Compile gitly with -autofree (non-blocking, vlang/v#30190) | continue-on-error: True
ubuntu-tcc    -> Compile gitly with -autofree (non-blocking, vlang/v#30190) | continue-on-error: True

Merge Danger

Door: Two-way. CI configuration only; no product code, schema, or data. Reverting restores three steps that were red for upstream reasons.

Blast Radius: Three steps lose their hard-fail status. The -prod builds, plain builds, tests, and first_run all stay blocking, so a genuine regression in gitly's own code still fails the job.

The honest downside: a future gitly-side autofree breakage would now surface as an orange rather than a red step, and orange is easy to ignore. That is the trade being made, and it is made because the alternative is every PR in this repository being blocked by an upstream bug that has nothing to do with the change under review. The steps are kept rather than deleted precisely so the signal is still there.

I cannot execute GitHub Actions locally, so the runner behaviour is reasoned rather than tested. #292 fixes the actual compile failure; this change is what stops the remaining red steps from blocking a merge, and it is independent of #292.

[medvednikov]

The non-blocking -autofree step is a defensible isolated change, assuming the upstream bug remains. Please coordinate with #298 before merging both. #298 makes the following -prod step conditional on steps.compile_gitly_with_autofree.outcome == 'success'. GitHub Actions records outcome: failure for a failed step even when continue-on-error: true changes its conclusion to success. As a result, combining the PRs would skip production builds and subsequent tests, potentially leaving a green job with those checks never run. In #298, use the adjusted conclusion or (preferably) remove the redundant previous-step outcome chaining so continued failures can be followed by meaningful checks.

[metif12]

Done - addressed in the latest push.

[medvednikov]

Review follow-up: upstream vlang/v#30190 is now closed, and current vlib/net/util.v constructs a fresh error_with_code(...) rather than returning the borrowed module-level IError reported in the issue. Please re-test -autofree against current V before relaxing the check. If the original failure is gone across the affected platforms, this PR should be closed as obsolete rather than permanently converting a useful compiler check to non-blocking.

[metif12]

Verified upstream vlang/v#30190 is closed and current master vlib/net/util.v constructs a fresh error_with_code instead of returning the borrowed IError, so the -autofree premise is gone. Closing as obsolete per review - the check should stay blocking.