IllusionMH
commented
2 years ago What TS version is reported if you hover over TS language details in status bar?
Built-in TS version in VS Code insiders is 4.7.3 which doesn't report error in this case.
Closed ZachHaber closed 1 year ago
IllusionMH
commented
2 years ago What TS version is reported if you hover over TS language details in status bar?
Built-in TS version in VS Code insiders is 4.7.3 which doesn't report error in this case.
ZachHaber
commented
2 years ago I've tested it with the built in 4.7.3, local 4.7.4, 4.7.3, 4.7.2, and 4.8-beta.
I also tested it on a fresh insiders install. Literally minutes before I made the issue.
ZachHaber
commented
2 years ago To show what I mean by the inconsistency with this bug. Randomly, it won't complain about the error until you modify the code, in which case it'll realize that it forgot to complain. https://user-images.githubusercontent.com/19843782/182628692-1d72352c-ceba-4c94-ba62-30e196e2be8c.mp4
The really weird thing about it is that the typescript language server both knows its fine and reports that error. For example, you can see that the type of makeStringBox is correct:
In addition to that, it appears that running the "Typescript: Reload Project" command fixes it until you change the code.
mjbvz
commented
2 years ago Here's the TS Server log for this case (using TS 4.8.0-dev.20220801):
Notice how semanticDiag returns an error in on initial load, but then doesn't once I type a space at the end of the file
xiaoxiangmoe
commented
1 year ago Temporary solution:
function makeBox<T>(value: T){
return {value};
}
const makeStringBox = (makeBox)<string>;
const stringBox = makeStringBox('abc');
jakebailey
commented
1 year ago I was able to reproduce this on the TS compiler itself, but only within the editor. In fact, building the project sometimes fixed the issue. Restarting TS does too.
export function instantiateIsNodeArray<T extends Node>() {
return isNodeArray<T>;
}I've had no success in making a test that reproduces it, though. I did a little debugging, and I feel like the problem is in getSymbolOfNameOrPropertyAccessExpression, for this name, isHeritageClauseElementIdentifier returns true, but then things go wrong beacuse ExpressionWithTypeArguments are no longer things that can only appear in type space (and so the decision about meaning appears to be wrong).
BrendanKelowna
commented
1 year ago I was having this problem until I ran npm ci
DanielRosenwasser
commented
1 year ago The repro we had today was
export function foo<U>() {
/*$*/return bar<U>;
}
export function bar<T>(x: T) {
return x;
}
let x = foo()(42);// at the /*$*/ cursor.//Expected: No errors.
Actual: 'bar' refers to a value, but is being used as a type here. Did you mean 'typeof bar'?
DanielRosenwasser
commented
1 year ago As @jakebailey has mentioned, I do feel like this is not a parsing bug. If you hover over foo in my example, it correctly displays the following:
function foo<U>(): <U>(x: U) => USEMANTIC HIGHLIGHTING!!!!!
jakebailey
commented
1 year ago That's one thing I suspect, but I tested with it disabled and also hit it, so I think there may be more (but maybe I'm wrong).
DanielRosenwasser
commented
1 year ago Okay, here's what I believe happens - you can notice in in two ways:
getErr request.bar. That triggers the same bad lookup behavior, which reports an error which gets reported in any following diagnostics request.
Type: Bug
VS Code version: Code - Insiders 1.70.0-insider (e9bda7aa4ff76648cfccc1a7bde465443803da71, 2022-08-02T16:56:25.649Z) OS version: Windows_NT x64 10.0.19044 Modes:
System Info
|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz (16 x 3600)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.92GB (17.88GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|
A/B Experiments
``` vsliv695:30137379 vsins829:30139715 vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 vslsvsres303:30308271 pythonvspyl392:30422396 pythontb:30258533 pythonptprofiler:30281269 vsdfh931:30280409 vshan820:30294714 pythondataviewer:30285072 vscod805:30301674 bridge0708:30335490 bridge0723:30353136 vsaa593cf:30376535 pythonvs932:30404738 wslgetstarted:30449409 vscscmwlcmt:30465136 cppdebug:30492333 vscaac:30438845 pylanb8912:30522163 vsclangdf:30492506 c4g48928:30535728 ```I've had this issue with both no npm packages installed. With typescript installed only. And with typescript and a tsconfig.json file.
Note: It is incredibly inconsistent. Sometimes it doesn't happen. Other times changing from the built-in version of typescript to the local version fixes it, sometimes just waiting fixes it. Until you change the code at all (adding/removing whitespace for example) and then it comes back. Installing a different version of typescript removes the error until you change the code as well.
I believe that this is a VSCode centric issue and not a Typescript issue for 2 reasons.
npx tscbuilds the package just fine without any issues from type errors.