compilepkg for cgo targets fails with nogo and --collect_code_coverage enabled

[xytan0056]

What version of rules_go are you using?

0.45.1

What version of gazelle are you using?

0.35.0

What version of Bazel are you using?

6.4.0

Does this issue reproduce with the latest releases of all the above?

yes

What operating system and processor architecture are you using?

➜  cgo_test git:(main) go env GOHOSTARCH GOHOSTOS
amd64
linux

Any other potentially useful information about your toolchain?

issue is reproducible, with or without hermetic C toolchain

What did you do?

minimal repro: https://github.com/xytan0056/cgo_test
force enable nogo here

bazel build ":project" --collect_code_coverage

What did you expect to see?

build pass

What did you see instead?

compilepkg: open bazel-out/k8-fastbuild/bin/project_/_cgo_install.h: file exists

with context

ERROR: /home/user/cgo_test/BUILD.bazel:40:10: GoCompilePkg project.a failed: (Exit 1): builder failed: error executing command bazel-out/path/to/bin/external/go_sdk/builder_reset/builder compilepkg -sdk external/go_sdk -installsuffix linux_amd64 -src main.go -src add.c -src add.h -embedroot '' -embedroot ... (remaining 49 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
compilepkg: open bazel-out/k8-fastbuild/bin/project_/_cgo_install.h: file exists
Target //:project failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 7.345s, Critical Path: 1.49s
INFO: 41 processes: 6 internal, 35 processwrapper-sandbox.
FAILED: Build did NOT complete successfully

Note

However after disabling nogo, build can pass

[fmeum]

Cc @sluongng Do you happen to have an idea why our tests didn't catch this?

[sluongng]

Without looking too much into this, it's most likely happening here

https://github.com/bazelbuild/rules_go/blob/30099a6add3c43706b4eec82b773b78310874935/go/tools/builders/cgo2.go#L157-L161

we are "opening" 2 files to copy from one to another.

The error happens when the destination file already exists, which I am unsure why.

[fmeum]

This will be fixed by #3995