cmd/compile: unnamed functions missing FuncInfo

[prattmic]

Context: I am adding additional information to runtime.inlinedCall (function start line), which I am plumbing via the FuncInfo. In the linker, this FuncInfo.Valid() got me thinking that (IMO) inlined functions ought to always have a FuncInfo, since they must be Go functions, so I switched the check to panic if it is missing.

This program fails that check:

package main

func main() {
        var i int
        fn := func() { i++ }
        fn()

        func() { i++ }()
}

panic: inlined function main.main.func2 missing func info

goroutine 1 [running]:
cmd/link/internal/ld.genInlTreeSym(0xc000510000?, 0x200000010?, {0xc000510000, 0xc000166080, {0xc00016888d, 0x48, 0x48}, {0x1, 0x10, 0x2, ...}}, ...)
        /usr/local/google/home/mpratt/src/go/src/cmd/link/internal/ld/pcln.go:172 +0x419
cmd/link/internal/ld.makeInlSyms(0xc000158000, {0xc000a5a000, 0x40c, 0x40c?}, 0x20?)
        /usr/local/google/home/mpratt/src/go/src/cmd/link/internal/ld/pcln.go:194 +0x245
cmd/link/internal/ld.(*Link).pclntab(0xc000158000, {0xc000105900?, 0x1?, 0xf?})
        /usr/local/google/home/mpratt/src/go/src/cmd/link/internal/ld/pcln.go:786 +0x1e6
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0x0, 0x0}, {0x6886dd, ...}, ...})
        /usr/local/google/home/mpratt/src/go/src/cmd/link/internal/ld/main.go:328 +0x144a
main.main()
        /usr/local/google/home/mpratt/src/go/src/cmd/link/main.go:72 +0xedb

The first closure (fn) has a FuncInfo, but the second does not. This seems like a bug to me, though it probably had low impact before because FuncID would default to FuncID_normal anyways.

I am still digging, but it looks like this is somewhere in the compiler, as func2 never makes it to ssagen.InitLSym, which sets up the FuncInfo.

cc @golang/compiler @cherrymui

[prattmic]

Note to self: enqueueFunc skips both func1 and func2 because they aren't trivial closures. When enqueueing main.main, the later loop prepares func1, but for some reason func2 never ends up in next.Closures.

[mdempsky]

@prattmic Without looking too closely, I think it's because the directly called closure gets inlined and then we know there won't be any other references to it, so we intentionally drop references to it from the AST because we know we don't need to compile its function body on its own. (Contrast that the indirectly called closure gets inlined too, but we don't do any frontend analysis to realize that was the only possible use.)

[cuonglm]

The place where the direct call closure is replaced: https://cs.opensource.google/go/go/+/refs/tags/go1.19.1:src/cmd/compile/internal/inline/inl.go;l=596

Maybe we can mark it as need lsym and call ssagen.IniLSym in enqueueFunc if the closure was marked.

[gopherbot]

Change https://go.dev/cl/429637 mentions this issue: cmd/link/internal/ld: panic if inlined functions missing funcinfo

[gopherbot]

Change https://go.dev/cl/436240 mentions this issue: cmd/compile: eagerly create LSym for closures