CL 153841 needed to create local temporaries in "init" to handle when f(g()) appears in a package-scope initialization statement.

But the concurrently developed CL 159717 moved initialization statements to run in "init.ializer" instead of "init."

The result was entirely unsafe because initialization statements compiled within "init.ializer" were referring to local variables in "init," but it seems like there weren't any compiler consistency checks that noticed this. It was only detected because net/http/pprof happened to fail very loudly at runtime when built with -gcflags=-N.

Granted maybe CL 153841 was being too clever with its solution to "init" (now "init.ializer") not yet existing and it's worth revisiting whether "init.ializer" can be created earlier, but it still surprised me that the backend didn't notice it was using a PAUTO variable from another function.