Context: I am adding additional information to runtime.inlinedCall (function start line), which I am plumbing via the FuncInfo. In the linker, thisFuncInfo.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.
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.
@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.)
All inlined functions are Go functions, and thus should be capable of
having a FuncInfo. Missing FuncInfo is likely indication of a compiler
bug that dropped the symbol too early, failing to add it to the symbol
list used for writing output. I believe all existing cases have been
fixed; this check will prevent regressions.
The exception is -linkshared mode. There symbols are loaded from the
shared library, and the FuncInfo is not available. This is a bug, as it
can result in incorrect the FuncID in inlinedCall, but it is very
involved to fix.
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Matthew Dempsky <email@example.com>
Run-TryBot: Michael Pratt <firstname.lastname@example.org>
Reviewed-by: Cherry Mui <email@example.com>