[red-knot] assert that we don't create multiple definitions for one node

[carljm]

I don't think this should happen, and if it does that suggests a bug. But a quick attempt to add the assert caused a panic, so apparently we are already relying on this. We should figure out why/where, fix it, and add the assert.

[carljm]

See #13075 (comment) for previous attempt to add the assert.

[dylwil3]

It looks like it's only one corpus example that panics with the new debug assertion (commenting it out makes the test pass):

async def foo():
    l = {k: v async for k, v in gen()}
    return [i for i in l]

A more minimal example that causes a panic is this:

{i: j for i, j in gen}

In each case the repeated definition is the Comprehension.

All of the following cause the test to fail for the same reason:

{i: j for i, j in gen}
{i for i, j in gen}
{0: 0 for i,j in gen}
{0 for i,j in gen}
[i for i,j in gen]
[j for i,j in gen]
[0 for i,j in gen]

These cases pass:

{x[0]: x[1] for x in gen}
{0: 0 for x in gen}

So it seems like issue is the tuple of elements... and indeed, if you remove the debug_assert_eq and inspect how many definitions get added for

[_ for a,b,c,d,e in gen]

you'll find it's 5.

But that's as far as I got and I should probably go to sleep 💤

[carljm]

That's good data; looks like the problem is we don't handle unpacking in comprehension iteration vars.