[red-knot] Double-store assertions when encountering invalid syntax

[sharkdp]

During type inference on some invalid syntax examples, we encounter situations where the exact same expression appears in multiple places inside the AST. The smallest example I could find is this:

for

When parsing it, we get the following AST. Note that the same Name(…) expression (same range) appears both as target and as iter field on StmtFor, once with Store context, once with Invalid context:

Module(
    ModModule {
        range: 0..3,
        body: [
            For(
                StmtFor {
                    range: 0..3,
                    is_async: false,
                    target: Name(
                        ExprName {
                            range: 3..3,
                            id: Name(""),
                            ctx: Store,
                        },
                    ),
                    iter: Name(
                        ExprName {
                            range: 3..3,
                            id: Name(""),
                            ctx: Invalid,
                        },
                    ),
                    body: [],
                    orelse: [],
                },
            ),
        ],
    },
)

This leads to a subsequent failing double-store assertion in store_expression_type because we infer types for both the target and the iter expressions:

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 2176 to 2184 in f789b12

	fn store_expression_type(
	&mut self,
	expression: &impl HasScopedAstId<Id = ScopedExpressionId>,
	ty: Type<'db>,
	) {
	let expr_id = expression.scoped_ast_id(self.db, self.scope());
	let previous = self.types.expressions.insert(expr_id, ty);
	assert_eq!(previous, None);
	}

I'm not sure how to fix this.

Skipping storage when encountering expressions with Invalid context would work for this example, but there are other cases (:x=) where such an invalid expression is not "backed up" by a second valid expression.

Ignoring double-storage for Invalid expressions is also not an option, since in this example here, we run inference on iter first.

[MichaReiser]

Hmm, this is interesting. We could consider using the ptr address instead of Range + Kind

[sharkdp]

A similar example is

x if $z

Mentioning it here because it leads to a slightly different panic (Calling self.infer_expression on a standalone-expression is not allowed…). But the underlying issue is the same, I believe.