@mdempsky

It depends upon inlining fail -- if that is //go:noinline it passes. I.e., there is a problem w/ constant propagating the function value.

Here's a reproducer with a smaller AST: https://go.dev/play/p/FGmrix8m3nh?v=gotip

Thanks! There's something going on with the inliner and ir.reassigned.

During inlining of inlined(true) into main, we create new eff and isTrue local variables for main, and then generate a function body to use them, which can ultimately be substituted for the original function call in main.

But it seems like we're trying to recursively inline the resulting expanded body before it's been substituted into main. So when we called ir.reassigned(eff) to see whether it's been reassigned, we end up looking at the main, but we won't yet see any assignments to it. And thus the inliner decides it's safe to assume eff is never reassigned, and the call to eff() is always to fail.

I think the nounified frontend avoids this inliner bug, because it doesn't set Defn on local variables constructed during inlining, so we'd never inline calls in this case anyway.

Even further minimized repro: https://go.dev/play/p/jDtyqFOdFlB?v=gotip

Variation of the bug that affects Go 1.19: https://go.dev/play/p/Orb0U2fXXhB

Change https://go.dev/cl/425257 mentions this issue: cmd/compile: defer transitive inlining until after AST is edited