A property that does not resolve is named in the error, in a condition too (#442)

[ASDAlexander77]

Part 2 of #442. Part 1, a.map(f).map(g) without the default library, was fixed by #443.

if (o.foo) on an object with no foo reported only "the condition has no value". const v = o.foo reported only "can't resolve name: v". Neither error named the property.

The failure happens in the run that infers the function's return type (allowPartialResolve). In that run, mlirGenPropertyAccessExpression returns success with no value and no message, so that a sibling method an object literal hasn't registered yet can resolve in a later run. The compile then fails in that same run, on what the caller makes of the missing value. The real run, which would have said "Can't resolve property", is never reached.

The access now reports the error in that run too, and still returns success:

c1.ts:3:9: error: Can't resolve property 'foo' of type {x:s32}
c1.ts:3:5: error: the condition has no value

This changes nothing for a property that resolves later. A message is shown only if the module fails to compile, and each retry cycle in processStatements starts with no messages.

New tests property-error/{if,const,while,conditional}.ts expect the property's name in the error; on main none of these programs names it.

Gate	Result
Windows full suite (Release)	3826/3826
Linux (WSL) full suite	3811/3811
DefaultLib suite, release + debug, compile + JIT	gc 159/159; rc, none 158/159 (weakref_basic is gc-only, as on main)
own corpus	no flips, and no first-error text changed (460/618)

Closes #442

🤖 Generated with Claude Code