nogo broken with ".facts" errors in 0.50.0

[aran]

What version of rules_go are you using?

0.50.0

What version of gazelle are you using?

0.38.0

What version of Bazel are you using?

7.3.1

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

I think those are the latest

What operating system and processor architecture are you using?

macos/m2

Any other potentially useful information about your toolchain?

go_sdk 1.23.0

nogo set up:

load("@rules_go//go:def.bzl", "TOOLS_NOGO", "nogo")

nogo(
    name = "nogo",
    visibility = ["//visibility:public"],
    deps = TOOLS_NOGO,
)

What did you do?

In upgrading to 0.50.0, many go targets now fail with:

WARNING: Remote Cache: Expected output <...>/mycode.facts was not created locally.
WARNING: Remote Cache: Expected output <...>/mycode_lib.facts was not created locally.
ERROR: <mycode>/BUILD.bazel:3:11: output '<...>/mycode_lib.facts' was not created
ERROR: <mycode>/BUILD.bazel:10:10: output '<...>/mycode_lib.facts' was not created
ERROR: <mycode>/BUILD.bazel:10:10: Running nogo on <mycode>:mycode failed: not all outputs were created or valid
ERROR: <mycode>/BUILD.bazel:3:11: Running nogo on <mycode>:mycode_lib failed: not all outputs were created or valid

I tried clearing my `--disk_cache` target with no effect.

Removing `go_sdk.nogo(nogo = "...:nogo")` allows a successful build of all targets.


### What did you expect to see?

Successful build. 

### What did you see instead?

Errors referring to missing '.facts' files.

[fmeum]

Basic usage like that is covered by tests, so there must be something else about your targets that tickles the bug. Could you try to cut down one of the failing targets to the point that you can share it?

[aran]

https://github.com/aran/rules_go_4084 is small and has the issue for me. I also ran bazel clean --expunge to try it out. Just building with bazel build //..., it works without the nogo line in MODULE.bazel, and fails with the line present.

[fmeum]

I have no idea why there is no error message in this case, but when I commented out the last of the analyzers in TOOLS_NOGO as an attempt to bisect the problem, I saw this panic:

panic: any

goroutine 39 [running]:
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f06248, 0x14000126cc0}, 0x0?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:269 +0x3e0
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f061d0, 0x140002adb00}, 0x10?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:261 +0x4b8
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f06090, 0x14000175f10}, 0xc0?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:208 +0xd4
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f061d0, 0x140002adbc0}, 0x70?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:261 +0x4b8
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f06090, 0x140002c8070}, 0x40?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:208 +0xd4
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f06158, 0x140002b6b40}, 0x50?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:222 +0x160
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f061d0, 0x140002adc50}, 0x70?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:261 +0x4b8
golang.org/x/tools/go/ssa.forEachReachable.func1({0x104f061a8, 0x140002b7070}, 0xb8?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:208 +0xd4
golang.org/x/tools/go/ssa.forEachReachable(0x140004cadc8?, {0x104f061a8?, 0x140002b7070?}, 0x104deffe0?)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/methods.go:272 +0x60
golang.org/x/tools/go/ssa.addRuntimeType(0x104f061a8?, {0x104f061a8?, 0x140002b7070?})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2601 +0xe8
golang.org/x/tools/go/ssa.emitConv(0x140004c4000, {0x104f09178, 0x14000480540}, {0x104f06090, 0x14000174e00})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/emit.go:250 +0x400
golang.org/x/tools/go/ssa.(*builder).emitCallArgs(0x1400001e550, 0x140004c4000, 0x140001d5680, 0x14000127900, {0x0?, 0x0, 0x78?})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:1044 +0x23c
golang.org/x/tools/go/ssa.(*builder).setCall(0x1400001e550, 0x140004c4000, 0x14000127900, 0x1400002a840)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:1089 +0x80
golang.org/x/tools/go/ssa.(*builder).expr0(0x1400001e550, 0x140004c4000, {0x104f068e8?, 0x14000127900}, {0x7, {0x104f06090, 0x14000174e70}, {0x0, 0x0}})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:666 +0x215c
golang.org/x/tools/go/ssa.(*builder).expr(0x1400001e550, 0x140004c4000, {0x104f068e8, 0x14000127900})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:585 +0x11c
golang.org/x/tools/go/ssa.(*builder).assign(0x1400001e550?, 0x140004c4000, {0x104f07298, 0x1400007c6f0}, {0x104f068e8?, 0x14000127900?}, 0x48?, 0x140004e3658)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:558 +0x2f8
golang.org/x/tools/go/ssa.(*builder).assignStmt(0x1400001e550, 0x140004c4000, {0x14000113ab0, 0x1, 0x1?}, {0x14000113ad0, 0x1, 0x19?}, 0x1)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:1167 +0x318
golang.org/x/tools/go/ssa.(*builder).stmt(0x1400001e550, 0x140004c4000, {0x104f06b28?, 0x14000127940?})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2371 +0x8b4
golang.org/x/tools/go/ssa.(*builder).stmtList(...)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:910
golang.org/x/tools/go/ssa.(*builder).stmt(0x1400001e550, 0x140004c4000, {0x104f06a38?, 0x1400010b5c0?})
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2467 +0xbf0
golang.org/x/tools/go/ssa.(*builder).buildFromSyntax(0x1400001e550, 0x140004c4000)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2579 +0x204
golang.org/x/tools/go/ssa.(*builder).buildFunction(0x104ebd501?, 0x140004c4000)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2533 +0x110
golang.org/x/tools/go/ssa.(*builder).iterate(0x1400001e550)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2521 +0x2c
golang.org/x/tools/go/ssa.(*Package).build(0x1400002a400)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2650 +0xa4
sync.(*Once).doSlow(0x1400007e270?, 0x14000122e40?)
	GOROOT/src/sync/once.go:76 +0xf8
sync.(*Once).Do(...)
	GOROOT/src/sync/once.go:67
golang.org/x/tools/go/ssa.(*Package).Build(...)
	external/gazelle~~go_deps~org_golang_x_tools/go/ssa/builder.go:2639
golang.org/x/tools/go/analysis/passes/buildssa.run(0x1400007e1a0)
	external/gazelle~~go_deps~org_golang_x_tools/go/analysis/passes/buildssa/buildssa.go:59 +0x270
main.(*action).execOnce(0x1400011b360)
	external/rules_go~/go/tools/builders/nogo_main.go:376 +0x728
sync.(*Once).doSlow(0x0?, 0x0?)
	GOROOT/src/sync/once.go:76 +0xf8
sync.(*Once).Do(...)
	GOROOT/src/sync/once.go:67
main.(*action).exec(...)
	external/rules_go~/go/tools/builders/nogo_main.go:305
main.execAll.func1(0x0?)
	external/rules_go~/go/tools/builders/nogo_main.go:299 +0x6c
created by main.execAll in goroutine 1
	external/rules_go~/go/tools/builders/nogo_main.go:297 +0x4c

This makes me think that this is an issue in golang.org/x/tools and indeed, after bazel run @rules_go//go get golang.org/x/tools, the issue is gone.

@tyler-french We probably have to update golang.org/x/tools when we switch to Go 1.23.0 in CI.

[aran]

Thanks for looking. That's a great help. In case anyone else stumbles here, I can workaround with this addition to MODULE.bazel:

# TODO: Remove when https://github.com/bazelbuild/rules_go/issues/4084 is resolved 
go_deps.module(
    path = "golang.org/x/tools",
    # curl https://sum.golang.org/lookup/golang.org/x/tools@v0.24.0
    sum = "h1:J1shsA93PJUEVaUSaay7UXAyE8aimq3GW0pjlolpa24=",
    version = "v0.24.0",
)

and adding it to the go_deps:

use_repo(
    go_deps,
     ...
     "org_golang_x_tools",
     ...

[seh]

What work remains to be done here in order to fix this problem? It's hard to tell from reading the preceding comments whether there's a change required in this repository, or if we're waiting on a fix in an upstream dependency.

[fmeum]

It needs a bump of x/tools in go.mod (but nothing else). Since that repo is rather unstable, I don't want to force the update on everyone just yet. It's arguably the end user's duty to update and control the versions of these deps.

[seh]

Oh, does that mean that if my own go.mod file requires a new enough version of that x/tools module that I'd wind up fixing this for myself?

At present, my go.mod file declares a(n indirect) dependency at version 0.24.0.

[fmeum]

That should work if you are using Bzlmod and go_deps. If not, then your own go_repository would collide with the one defined as a dep of rules_go.

[jbedard]

I'm running into this as well and the workaround from @aran works for now, thanks for the snippet!