-
Notifications
You must be signed in to change notification settings - Fork 12.8k
isArray type guards still causing issues in latest nightly build #42768
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
That's likely the result of microsoft/vscode#102413 which used to rely on some of the changes - I've shipped microsoft/vscode#116571 which reverts those changes too |
Thanks for taking a look. After merging that commit however, I'm still seeing these errors. I tested with both the latest nightly and the 4.2-rc. It looks like this location for example is using the standard |
It looks like this code only worked on nightly builds of 4.2 while the isArray narrowing was still in and before it got pulled out prior to the RC. Correctly narrowing via this check isArray seems to be a lot of trade-offs which we've concluded broke too much prod code. I've re-opened #31155 which is the underlaying issue (switch 'instanceof' with 'Array.isArray' for this explanation #31155 (comment) You can try this playground with any of the prod builds in the versions (and then try IMO, this probably needs code changes on the vscode side, perhaps shuffling around the narrowing fields (which I don't think is too satisfying) |
Thanks. The function itself hasn't changed but we did make one of the type declare const x: string | readonly string[]
if (!Array.isArray(x)) {
x.toLocaleLowerCase() // Property 'toLocaleLowerCase' does not exist on type 'string | readonly string[]'.
} I'll look into adding casts or something to workaround this |
Roughly what's happening: a I agree its a bug though, you'd expect that to work which was why we originally tried to propagate the readonly through |
I ran into a similar problem. I believe that interface ArrayConstructor {
isArray(arg: any): arg is readonly any[];
} This fixes the present issues and produces expected behavior. I also believe it better reflects the behavior of that function. See the following test cases: declare const foo: number | number[];
declare const bar: number | readonly number[];
// Original version:
declare function isArray(arg: any): arg is any[];
if (isArray(foo)) {
foo.indexOf(42); // ✅ pass; 'foo' is number[]
foo.indexOf("Not a number"); // ✅ error
} else {
foo + 1; // ✅ pass
}
if (isArray(bar)) {
bar.indexOf(42); // ❌ unexpected: 'foo' becomes any[]
bar.indexOf("Not a number"); // ❌ unexpected: should error
} else {
bar + 1; // ❌ unexpected: should pass
}
// Fixed version:
declare function isArrayFixed(arg: any): arg is readonly any[];
if (isArrayFixed(foo)) {
foo.indexOf(42); // ✅ pass; 'foo' is number[]
foo.indexOf("Not a number"); // ✅ error
} else {
foo + 1; // ✅ pass
}
if (isArrayFixed(bar)) {
bar.indexOf(42); // ✅ pass; 'bar' is readonly number[]
bar.indexOf("Not a number"); // ✅ error
} else {
bar + 1; // ✅ pass
} |
Bug Report
🔎 Search Terms
🕗 Version & Regression Information
Tested in 4.3.0-dev.20210211 which
💻 Code
In the VS Code codebase, we are still seeing the
isArray
type guards causing problems with the latest TS 4.3 nightly build.Here's an example from this file
The type of
DocumentSelector
isstring | vscode.DocumentFilter | readonly (string | vscode.DocumentFilter)[]
The error in the
else
block on the linelanguage: selector.language
:These errors did not show up with
typescript@4.2.0-dev.20201207
.Here are the other errors:
@orta @RyanCavanaugh I believed that #41851 was supposed to fix these issues. Can you please take a look at our errors and me know if we need to change anything on the VS Code side or if these are unexpected errors
The text was updated successfully, but these errors were encountered: