An unresolved call in an action body suppresses registration of every property declared later in the same module, producing phantom "is not found" errors

[CrushBy]

Description

When an action body contains a call that cannot be resolved, every property declared after that action in the same module silently fails to register. Later uses of those properties are then reported as property or action 'x[...]' is not found, even though they are declared correctly and earlier than their use.

Actions declared after the faulty one are unaffected. Properties declared before it are unaffected. It does not matter whether the unresolved call is an unknown name or an existing name called with a wrong signature.

The practical cost is diagnostic. In a real ~330-line module a single mistake (an unbracketed OVERRIDE comma inside an argument list, which reshapes the argument list so the call no longer matches the action's signature) produced 6 errors, 5 of them phantom, scattered across the whole file — including a component 'BOX(dl)' is not found from the form section. Fixing the single real error removed all six. In the reported list the root cause is not distinguishable from its consequences, which sent me looking for a non-existent second bug.

Version: 7.0-SNAPSHOT (build 392), Java 17.0.9, Windows. Reproduced via settings.dryRun.

Minimal reproduction

MODULE ZReproF;

REQUIRE System;

NAMESPACE ZReproF;

CLASS A 'A';
f 'F' = DATA INTEGER (A);

// the ONLY mistake: a call to a name that does not exist at all
bad 'Bad' (A a) {
    noSuchAction(a);
}

// declared AFTER the faulty action - correct in itself
h 'H' = DATA INTEGER (A);

FORM repro 'Repro'
    OBJECTS a = A
    PROPERTIES(a) f, h
;

Actual

[error]: ZReproF:12:19 action 'noSuchAction[ZReproF.A]' is not found
[error]: ZReproF:20:22 property or action 'h[ZReproF.A]' is not found

Expected

Only the first error. h is declared at line 16 and used at line 20.

Isolation

Six single-module variants, differing only in the marked dimension:

variant	error in the action body	declared after it	phantom error
A	unknown name	action	no
F	unknown name	DATA property	yes
B	wrong signature	DATA property	yes
C	wrong signature	property declared before the action	no
D	wrong signature	action	no
E	wrong signature	calculated property	yes

The "wrong signature" variants use this shape, where the OVERRIDE operand list swallows the remaining arguments:

target 'Target' (A a, INTEGER x, INTEGER y) {
    f(a) <- x;
    g(a) <- y;
}

bad 'Bad' (A a) {
    target(a, OVERRIDE f(a), 0, 5);     // -> target[A,INTEGER] is not found
}

h 'H' = DATA INTEGER (A);               // -> h[A] is not found  (phantom)

Causality is established by variant B: bracketing the OVERRIDE and changing nothing else — target(a, (OVERRIDE f(a), 0), 5); — makes both errors disappear and the module compiles clean.

Suggested fix

Either would remove the diagnostic cost:

1. Keep registering declarations after a failed action body, so the phantom errors never appear; or
2. Suppress the consequent errors and report N further errors suppressed as likely consequences of the error at line 12.