@weswigham , looks like some order changes still remain. I thought they were fixed by now?

groans I'm not sorting by elaboration (or lack thereof) so an error that occurs on the exact same location but is only elaborated once is unstable. sigh

Though that brings up a decent point, imo: why aren't the errors deduped?

Um, might be a bug in our error reporting?

Looks like they're all assignability issues; I'm pretty sure we have OK reasons to check assignability a few times (even at the same place? Probably worth looking at...) - I think our deduplication logic just doesn't ignore elaborations when comparing errors?

@sandersn Here's a reduced example of the code causing the error:

// @ts-check
var A = {};
A.B = {};
/** @typedef {{o: string, y: number}} */
A.B.C = [
    {
        o: "no",
        y: 42
    },
    {
        o: "yes",
        y: 0
    }
];

/**
 * @returns {?A.B.C}
 */
function foo() {
    return A.B.C.find(x => !!x);
}

(The typedef is supposed to be pulling its name from the following assignment's LHS, but instead gets a parse error - then later in the function below we claim to return that type, but since the typedef fails, the odd js "falls back to the value type" behavior happens and we error because, ofc, an element of the array isn't assignable to the array itself)

Modifying the example like so:

// @ts-check
var A = {};
A.B = {};
/** @typedef {{o: string, y: number}} */
A.B.C = [
    {
        o: "no",
        y: 42
    },
    {
        o: "yes",
        y: 0
    }
];

A.B.Foo = class {
    /**
     * @returns {?A.B.C}
     */
    foo() {
        return A.B.C.find(x => !!x);
    }
}

causes the assignability error to be repeated! (Once with elaboration, once without)