Repository navigation
Opening files in different order in IDE produces different errors #1953
Description
0.ts:
///<reference path="1.ts"/>
///<reference path="2.ts"/>
var i: A | B;
var param: any;
i.foo(param); // May or may not produce an error1.ts:
///<reference path="0.ts"/>
///<reference path="2.ts"/>
interface A {
foo(): string;
}2.ts:
///<reference path="0.ts"/>
///<reference path="1.ts"/>
interface B {
foo(x?): string;
}These three files form a clique because they all reference each other. If you start with none of these files open, and then open them, you may or may not get an error depending on the order that you open the files. Specifically, if you open file 0.ts or 1.ts first, you get an error. But if you open 2.ts first, you get no error.
This has to do with the nondeterministic order of types for union type collapsing.
This also means that the order the IDE calls getSemanticDiagnostics on the files is important, as it could lead to different outcomes. For compile-on-save, we call getSemanticDiagnostics on just the file we are saving. But in order to get a consistent outcome, we would have to call getSemanicDiagnostics on all the files in a canonical order, every time a file is saved. This means many files may have to be type checked before you can emit the file you've saved.
Activity
JsonFreeman commentedon Apr 22, 2015
This could be fixed by adding a stricter subtype rule for optional parameters versus absent parameters
mhegazy commentedon Jul 27, 2015
This should be fixed after the strict object literal changes
DanielRosenwasser commentedon Jul 30, 2015
What exactly is the reason for that?
danquirk commentedon Jul 30, 2015
Daniel Rosenwasser (@DanielRosenwasser) I believe because
This has to do with the nondeterministic order of types for union type collapsing.
is no longer relevant as subtype reduction for union types was removed as part of the strict object literal changes. We should double check that this actually no longer repros though.
JsonFreeman commentedon Jul 30, 2015
It isn't really because we eliminated subtype reduction in that change. We did in fact eliminate subtype reduction. But more importantly we eliminating the sorting of union constituents by type id. That was the source of the nondeterminism.