cmd/compile: walkConvInterface produces broken IR [1.19 backport]

[gopherbot]

@cuonglm requested issue #56768 to be considered for backport to the next 1.19 minor release.

@gopherbot please backport this to go1.19

Some static initialization code causes the compiler to crash.

[toothrot]

@cuonglm Hello! Could you please provide rationale as per https://go.dev/wiki/MinorReleases?

[cuonglm]

Hi @toothrot, I did add the rationale in the issue description:

Some static initialization code causes the compiler to crash.

[gopherbot]

Change https://go.dev/cl/451875 mentions this issue: [release-branch.go1.19] cmd/compile: fix broken IR for iface -> eface

[cherrymui]

Similar to #56744 , we'd need better understanding to decide whether we should backport this. Thanks.

[aclements]

Maybe other people understand this, but I'm confused by how we weren't covering this code path in walkConvInterface before. It seems like this code path would always result in an ICE, but it's been around since 57668b8 (Aug 2021). Were we actually never taking this code path until the fix for #56727, or is there something I'm missing about that fix that makes this path in walkConvInterface construct bad IR?

[cuonglm]

Maybe other people understand this, but I'm confused by how we weren't covering this code path in walkConvInterface before. It seems like this code path would always result in an ICE, but it's been around since 57668b8 (Aug 2021). Were we actually never taking this code path until the fix for #56727, or is there something I'm missing about that fix that makes this path in walkConvInterface construct bad IR?

Because after walkConvInterface produced bad IR, this bad IR is never typechecked, it's just pass to backend as-is. For OITAB, a generic pointer (*uintpr, *int32 ...) would satisfy the backend.

There're many places in the walk pass that we produce an ir.Node then call SetTypecheck(1), instead of calling typecheck.{Stmt,Expr} on generated node.

[aclements]

Ah, so just to clarify further, we were taking that code path in walkConvInterface before, but only in places where where we also called SetTypecheck(1)?

[cuonglm]

Ah, so just to clarify further, we were taking that code path in walkConvInterface before, but only in places where where we also called SetTypecheck(1)?

Yes. The problem is more hidden for walkConvInterface, since the bad IR is put into init nodes, so it's harder to trigger the bug. Only until the fix to order slice literal, walkStmtList is called on init nodes, the missing typecheck bug was reveal. Then to fix the missing typecheck bug, typecheck.Stmts was called, which reveal the type mismatch in itab assignment.