CC @dr2chase

The algorithm we use is not that clever and just tracks flow by variable name.
If/when we get around to moving escape analysis into the SSA phase (there are several difficult prerequisites in the way of this happening -- and these are planned, e.g., moving call expansion into SSA) this will be fixed as a side-effect.

Since there's an easy workaround and big blockers for the proper fix, I would not commit to fixing this in 1.12.

Do you have a list offhand of all the prerequisites for a new SSA-based escape analysis?

I think (but now I am a little bit less sure, but lack the time right now to be more sure):

• need generic opcodes to allow us to talk about making things on-stack-or-heap-but-not-sure-yet, to be resolved by escape analysis.
• calls expanded in SSA itself, not before (I think). At least, calls to newobject, right?
• need generic opcodes for unexpanded calls.
• (maybe) an early part of SSA made able to run across some or all of a package, since escape analysis is interprocedural within a package (I am having some second thoughts here, current analysis punts on cycles and thus we could break edges with worst-case punts and do things one function at a time). But we might not always punt on cycles; if we improve the analysis to be able to tell the difference between the spine of a list and the leaves of the list (CDR vs CAR, e.g.) then there will be profit in recursive analysis; we can obtain interesting fixed points (I prototyped this, then realized that inability to tell CAR from CDR meant the benefits were very minor).
• dealing with shared versus not for things allocated in a stack frame will force a revision of SSA form; anything shared is potentially modified by a call, anything local (that is not address-taken and passed in to call) is not.

In addition to that, I think we need to understand what the benefit would be. It's going to be a lot of work, I only want to undertake it if we expect some commensurate benefits.

One possible benefit, from talking to a guy at GopherCon (@cixel) who's interested in doing instrumentation for taint detection/analysis, is doing dataflow-informed instrumentation. Idea is that we'd transform to SSA, do whatever instrumentation we want (that might, in some cases, have effects on escape analysis -- and might also have effects on stack frames), then run escape analysis etc.

This is still a little hand-wavy. He's looking the code for tsan and msan, and modifying things at the AST level, but having the ability to do flow analysis would be helpful (I wonder if it might not also help tsan and msan)

Dup of #18300; TL;DR: escape analysis is not path sensitive.

See also #31501.