TypeScript 3.5 compile errors in the VS Code codebase #31380
Comments
|
Specific issues that seem like breaking changes:
|
|
I fixed many of these errors in microsoft/vscode@fd1ac75 |
|
microsoft/vscode@fd1ac75#diff-fed321a94e979ed6f2aaaf1001dbac36L17 Caused by #27089. We might consider reverting the lib change because this code is manifestly correct, but our lack of ability to narrow |
|
microsoft/vscode@fd1ac75#diff-4414fa1e065d93e77c72eec3db97c187L105 We previously inferred Again, this is a case of manifestly correct code where we need type facts here to express the fact that There's a case to be made that our rules around unary |
|
microsoft/vscode@fd1ac75#diff-11b5b53dd82e487bffdf3b724fad9d83L82 We prevented a hypothetical call of |
Type facts as they exist today can only remove types from a union, not "add negated types to an intersection", so it's moreso a shortcoming in the type facts system as it exists than some specific fact being missing. Simply put: The type to narrow to in the case where |
|
microsoft/vscode@fd1ac75#diff-6c07482b4bc75dfd16bc0d2239065809R162 Context: VS Code has The relevant calling code looks like this (simplified): return asJson(context).then(result => {
return result && result['experiments'];
});Most other uses of It's not clear how to proceed here since the code was quite unsafe to begin with. We should get a time machine and ban uninferrable type parameters. |
|
microsoft/vscode@fd1ac75#diff-1e9db0aff31fe7167a26aef6c4176a19R23 The failing example looks like this: let watcher = new ConfigWatcher<{}>(testFile);
let config = watcher.getConfig();
assert.ok(config);
assert.equal(Object.keys(config), 0);This is a hairy variant of the |
|
microsoft/vscode@fd1ac75#diff-641fa4cc338f106854e4b4a33964acbdR84 This is an extremely real error. Consider these three assignments:
|
|
microsoft/vscode@fd1ac75#diff-b7604f54db2a2f61d2bf5af1fcc5047fL391 I can't tell what's going on here; this doesn't error locally for me. The type is extremely complex. |
Let's take that discussion to the PR please |
|
microsoft/vscode@fd1ac75#diff-1ba53e60093143b29593e77afffaacb6L1036 microsoft/vscode@fd1ac75#diff-0b973b67f859d3b8fa68baec97534643R98 More instances of indexing in to a non-null-narrowed |
|
microsoft/vscode@fd1ac75#diff-0f1abf8ff5283dac48ea3231f2dddfa0R96 An interesting case. This is a typical unsound method declaration where the derived class needs a specialized object from a parallel class hierarchy and would be broken by a call through a base type alias. Method bivariance allows this, but until a subsequent change this was disallowed due to differing definitions of the return type of The change appears to be unnecessary due to the change (presumably made chronologically later as Matt was fixing stuff) to Update: Also microsoft/vscode@fd1ac75#diff-022291e875d46b01fc7f4e6ba724f466 |
|
microsoft/vscode@fd1ac75#diff-00578f406c825a8136fefeb491625f65L722 Bullet 2 from Matt's comment; #31381 |
|
@mjbvz Regarding this one This is an effect of #30769. The type |
|
microsoft/vscode@fd1ac75#diff-00578f406c825a8136fefeb491625f65L722 In 3.4, In 3.5, the The better fix is probably to annotate the untyped |
|
microsoft/vscode@fd1ac75#diff-4a12537872685c49f4dc5c42f1537c45 I don't understand what this change is doing. The only manifestation of the type parameter in |
|
microsoft/vscode@fd1ac75#diff-203c27e756d1503a7f55c19fd8440959R268 A simplified version: enum E { f, g }
type A = {
q?: E;
x?: string;
y?: string;
}
function set(a: A, key: keyof A, value: string) {
a[key] = value;
}This is a correct error; it happens that no one called A preferable fix would be to change the signature of |
|
Thank you for taking a look. For #31380 (comment), is that TS error or a VS Code error? I believe the only one that I think is really blocking us then is the d.ts change: #27089 |
It's a VS Code error IMO. The object has a field that is either surplus in one constituent of the union, or an incorrect type in the other constituent. |
ghost
mentioned this issue
|
Closing this as I believe the errors have all be addressed or are by-design |
|
Inferring
in the following: public foo<T>(target: T): void {
target.hasOwnProperty;
}Not sure if you are seeing this as a bug. It is certainly rather inconvenient because |
|
Pass That's exactly the class of error the constraint change is supposed to catch - you might want to say |
|
@weswigham good point. Althought the temptation is to write Thanks |
TypeScript Version: 3.5.0-dev.20190512
Repo
Build VS Code with TypeScript@next:
git clone https://github.com/microsoft/vscode.git cd vscode yarn add typescript@next yarn run watchPotential issues
There are 68 compile errors on
TS@next, compared to zero when compiling withTS@3.4.5:Some of these seem related to #30637 but other ones seem suspect (or should be noted in the breaking changes)
The text was updated successfully, but these errors were encountered: