Explain synthetic init wrappers in go/ssa and their impact on blank-import edge propagation

[Copilot]

Addressed a question about what "synthetic init wrappers" means in the context of the sideeffect imports feature and why they matter for impact propagation.

Context

In go/ssa, pkg.Func("init") returns a synthetic package initializer — a function generated entirely by the SSA builder with fn.Synthetic = "package initializer" and no source position (fn.Pos() == token.NoPos). It is not the user-written func init(). Instead, it orchestrates initialization by calling the real user-defined init functions (init#1, init#2, …) in order.

Problem

synthesiseBlankImportEdges builds edges using these synthetic init wrappers, but BuildGraph skips synthetic functions during call-graph traversal (isSynthetic() check). This breaks the propagation chain:

user change → init#1 → [synthetic init] → [synthetic importer init] → importer init#1
                              ↑ skipped by isSynthetic                ↑ skipped

A change to init#1 is tracked against its own key, but the call edge from init#1 into the synthetic wrapper is invisible to the graph walker — so impact never flows through blank-import edges into dependent services.

Resolution

Replied to the review comment with the above explanation. The underlying propagation gap (using non-synthetic init#N functions or explicitly including synthetic init→init edges in the reverse index) remains open for follow-up.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.